# Julius Holderer

Obstructions in Security-Aware Business Processes

Analysis, Detection, and Handling

# Obstructions in Security-Aware Business Processes

Julius Holderer

# Obstructions in Security-Aware Business Processes

Analysis, Detection, and Handling

Julius Holderer University of Freiburg Freiburg im Breisgau, Germany

The present text is the publication of the dissertation for the award of the degree of Doctor of Engineering (Dr.-Ing.) of the Faculty of Engineering of the Albert Ludwigs University of Freiburg im Breisgau with the title "Obstructions in Security-Aware Business Processes – Analysis, Detection, and Handling".

Place of the dissertation: Faculty of Engineering, University of Freiburg, Germany Date of the disputation: July 26th, 2021

Dean: Prof. Dr. Rolf Backofen

Reviewers: Prof. Dr. Dr. h.c. Günter Müller, Prof. Dr. Josep Carmona, Prof. Dr. Bernd Becker

This publication was supported by the Open Access Publication Fund of the Albert Ludwigs University of Freiburg.

ISBN 978-3-658-38153-0 ISBN 978-3-658-38154-7 (eBook) https://doi.org/10.1007/978-3-658-38154-7

© The Editor(s) (if applicable) and The Author(s) 2022. This book is an open access publication. **Open Access** This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.

The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Responsible Editor: Stefanie Eggert

This Springer Vieweg imprint is published by the registered company Springer Fachmedien Wiesbaden GmbH, part of Springer Nature.

The registered company address is: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

# **Acknowledgements**

First and foremost, I want to thank my advisor, Prof. Dr. Dr. h.c. Günter Müller, for continuously supporting, challenging, and mentoring me in a unique and everencouraging way throughout all the phases of this dissertation, my doctorate, and beyond. It is hard to summarize all his help and what I learned from him in research and as a person in brief. I feel most thankful for all of it!

Also, I want to thank my second advisor, Prof. Dr. Josep Carmona, for being part of the journey, especially for taking over the task as the second reviewer and examiner. The inspiring collaboration with him, my stay at Barcelona Tech, and the resulting research were crucial for me and my work.

I further want to thank Prof Dr. Bernd Becker for his time and readiness to be the third reviewer and examiner, which was necessary due to the reviewer constellation.

Much appreciation goes to my colleagues at the Institute of Computer Science and Social Studies and the Institute of Sustainable Systems Engineering and to further persons directly or indirectly involved with this work. Many thanks in particular to Adrian, Anja, Arnt, Björn, Christian B., Christian Z., Claus, Farbod, Georg, Markus, Nadine, Thomas S., Thomas K., Tomasz, Rafael, Richard, and Véronique for the support, good discussions, fruitful collaboration, and good times.

Finally, I am deeply grateful for my private environment and its invaluable and unconditional support, patience, and confidence!

# **Abstract**

The growing regulatory pressure on increasingly digitized businesses, for example to combat the growing number of corporate fraud cases, can have an obstructive effect on the execution of automated business processes. Such security-related obstructions occur when the implementation of regulations, that is, the enforcement of so-called safety properties, blocks the execution of business processes—in particular, the so-called liveness property of process completion. Those obstructions exemplify the conflicting goals between business processes and classic IT security. This thesis addresses this problem by describing how to widen this restricted behavior of business processes resulting from security controls to the broader scope that compliance provides as part of corporate governance. By handling obstructions, security in business processes is supposed to be improved. For this purpose, an indicator-based view of security that extends the classic IT security controls will be introduced.

The SecANet approach, which will be presented in the course of this work, will allow putting this field of tension into a well-founded, formal representation of security-aware processes that opens up acting within such a desired security-sensitive realm of maneuver. The SecANet encoding will create an extendable framework that addresses workflow obstructions and will support their comprehensive analysis and handling. Furthermore, the OLive-M and OLive-L approaches will illustrate how the SecANet approach can be applied to solve obstructions based on a process model or a process log, respectively. In order to complete the workflow in that context, based on indicators captured as costs, a certain yet still compliant degree of violation of safety properties is tolerated. The solutions allow for additional, eventually live, process execution sequences because they widen the behavioral framework restricted by classic IT security in a security-sensitive way.

For evaluation, a set of example models and process logs will be generated using sample models with different degrees of complexity. Experiments based on these inputs will empirically show characteristics and functionality of the proposed approach. Because of its practical setting, this approach is applicable to a range of practical applications. For example, it could recommend who shall perform which tasks in a so-called break-glass situation, or act as a delegation assistant to suggest potential best delegates (with fewest violations) to the delegator. A corresponding process-aware information system could automate these delegations and provide additional mitigating techniques to prioritize audits of affected cases. Moreover, the graphical view of obstruction analysis could help policy designers to deepen their understanding of security policies and to improve their own security policies.

# **Zusammenfassung**

Der wachsende regulatorische Druck auf immer stärker digitalisierte Unternehmen, der sich beispielsweise aus der Bekämpfung der zunehmenden Zahl von Betrugsfällen ergibt, kann sich hinderlich auf die Ausführung automatisierter Geschäftsprozesse auswirken. Es können sicherheitsbedingte Obstruktionen (i.S.v. Blockaden) auftreten, wenn die Implementierung von Regulierungen, insbesondere die Durchsetzung von Sicherheitseigenschaften (i.S.v. engl. safety), die Ausführung von Geschäftsprozessen, insbesondere die sogenannte Lebendigkeitseigenschaft (engl. liveness) des Prozessabschlusses, blockiert. Solche Obstruktionen verdeutlichen das Spannungsfeld zwischen den Zielen von Geschäftsprozessen und klassischer IT-Sicherheit. Die vorliegende Arbeit adressiert dieses Problem, indem sie beschreibt, wie das durch Sicherheitskontrollen eingeschränkte Verhalten von Geschäftsprozessen auf den Handlungsspielraum erweitert werden kann, der durch Einhaltung (engl. Compliance) der Grundsätze der Unternehmensführung und -kontrolle (engl. Corporate Governance) gesetzt ist. Auf diese Weise soll durch die Behandlung von Obstruktionen die Sicherheit in Geschäftsprozessen verbessert werden. Dabei wird eine indikatorbasierte Sicht auf Sicherheit als Erweiterung der Zugriffskontrolle eingeführt.

Der SecANet-Ansatz, der im Rahmen dieser Arbeit vorgestellt wird, erlaubt es, dieses Spannungsfeld in eine fundierte, formale Repräsentation sicherheitsorientierter Prozesse zu überführen, die ein Agieren innerhalb solch eines sicherheitssensiblen Handlungsraumes eröffnet. Die SecANet-Kodierung schafft ein erweiterbares Framework, das Obstruktionen in Arbeitsabläufen adressiert und deren umfassende Analyse und Behandlung ermöglicht. Darüber hinaus werden die Ansätze OLive-M und OLive-L als Anwendungsfälle vorgestellt, die veranschaulichen wie der SecANet-Ansatz zur Lösung von Obstruktionen auf der Grundlage eines Prozessmodells bzw. eines Prozessprotokolls (Prozess-Log) genutzt werden kann. Um eine obstruierten Prozess abzuschließen, wird dabei auf Basis der als Kosten erfassten Indikatoren ein immer noch konformer Grad der Verletzung von Sicherheitseigenschaften toleriert. So ermöglichen die Lösungen zusätzliche, schließlich "lebendige" Prozessausführungssequenzen, weil sie den Verhaltensraum, den die klassische IT-Sicherheit vorgibt, sicherheitssensitiv erweitern. Zur Evaluation wird eine Reihe von Beispielen von Prozessmodellen und Prozessprotokollen mit unterschiedlichen Komplexitätsgraden erzeugt. Experimente, die auf diesen Eingaben basieren, zeigen empirisch Charachetristika und Funktionalität des vorgeschlagenen Ansatzes.

Aufgrund der aus der Praxis abgeleiteten Ausrichtung der Arbeit, ergibt sich aus dem Ansatz auch eine Reihe von praktischen Anwendungen. Er könnte zum Beispiel verwendet werden, um zu empfehlen, wer welche Aufgaben in einer so genannten Break-Glass-Situation übernehmen soll, oder um als Delegationsassistent zu fungieren, welcher Delegierenden die potenziell besten Kandidaten zur Delegation (mit den wenigsten Sicherheitsverletzungen) vorschägt. Ein entsprechendes prozessorientiertes Informationssystem könnte diese Delegationen automatisieren und zusätzliche Verfahren zur Risikomitigation zur Verfügung stellen, welche die Prüfung der betroffenen Fälle priorisieren. Darüber hinaus könnten die durch den graphbasierten Modellierungsansatz gegebenen Visualisierungsmöglichkeiten der Obstruktionsanalyse Policy-Designern helfen, das Verständnis von Sicherheits-Policies zu vertiefen und diese zu verfeinern.

# **Contents**







# **List of Figures**





# **List of Tables**


# **1 Why the Automation of Regulation Can Obstruct Business Processes**

The recurring question as to whether regulation is appropriate or obstructive is becoming more and more urgent due to its ever-increasing pressure on businesses in a digitally enabled world. In the year 2017, a decade after the financial crisis, 56,321 regulatory alerts from more than 900 bodies were tracked worldwide. This is highlighted by the chief compliance officer (CCO) of HSBC bank who recently stated that "you have to build an industrial-scale operation just to digest all the regulatory changes" [83].

Certainly, the question if regulation is appropriate or rather obstructive for business is not new. It is valid for many instances in business, with specific attacker models. The attention for business models was first taken care off by the Sarbanes Oxley Act (SOX) of 2002. The so-called SOX paradox describes a situation where the need for compliance and internal controls can reduce the ability of a company to be agile and dynamic in the marketplace. This scenario is paradoxical because the internal controls that must be documented under SOX are meant to help a company perform well and meet its financial goals [196]. The preceding American Patriot Act, which targeted money flowing to terrorists and other perpetrators after the September 11 attacks, had comparable side effects. The question emerged if requirements of costly "Know Your Customer" initiatives were disproportionate to the risk of money laundering and were rather obstructing business with normal bank customers [96]. Similar problems have recently been observed with respect to the General Data Protection Regulation of the European Union (GDPR), by which especially small and mid-sized businesses were overstrained by a plethora of regulatory requirements. Indeed, there are different ways how regulation can obstruct business. The sheer personnel effort and working hours needed for checking and ensuring compliance to regulation, or the burden of keeping track of the abundance of regulations and their implementation are just common examples. However, basic regulatory concepts and control functions in a business, especially internal controls

<sup>©</sup> The Author(s) 2022

J. Holderer, *Obstructions in Security-Aware Business Processes*, https://doi.org/10.1007/978-3-658-38154-7\_1

may act obstructive as well. Here, **authorization** or the assignment of permissions, for instance the right of a process participant to execute a certain process activity, internal control should ideally apply the principle of least privilege. According to this principle, process participants should only have access to the resources that are indispensable to perform their job responsibilities. By this for example access from unwanted staff can be avoided and the risk of fraud can be reduced without being too restrictive. **Separation of duties (SoD)** is known to be the quintessential internal control practice to avoid fraud. The institute of internal auditors (IIA) calls SoD a fundamental element of internal control for the segregation of certain key duties. The basic idea underlying SoD is that neither one employee nor a group of employees should be in a position to perpetrate or conceal errors or fraud in the normal course of their duties. In general, the principal incompatible duties to be segregated are [20] (1) the custody of assets, (2) authorization or approval of related transactions affecting those assets, and (3) recording or reporting of related transactions. For instance, such controls restricting access to business process activities can lead to staff shortages which can directly obstruct behavioral possibilities and restrict the scope of action of a business. Instead of a SoD rule, authorization can also be chosen so restrictively that an SoD conflict cannot occur at all. This however also restricts the flexibility, namely the possible user-task assignments. Hence, both authorization and further rules such as SOD are in control of the process executors. Their utilization expresses the risk a company is willing to take.

Foremost, regulation originates from combating financial crime and fraud. The scale and impact of corporate fraud has increased significantly in today's digital world. Regulation, fraud and digitization are in a feedback loop in which the latter is the driving force. Its prerequisites are data and processes [152]. Digitization or the digital transformation are often directly connected with the digitization of business processes and (robotic) process automation, i.e., processes are more and more computer-supported. A current McKinsey survey of almost 1,000 top managers supports this. Those surveyed rank "automation and/or improvement of business processes" (besides the digitized integration of customers and digitized innovation processes) among the most prioritized opportunities in the digitized economy. Hence, operations in enterprises are ultimately all attributable to digital representations of processes, be it healthcare, finance, transportation or manufacturing. Therefore, regulation must operate on these processes and the information systems that enact them.

With the digitization and the automation of business processes, it seems as if the "burden" of regulation could be eased if regulation was also automated. Automating the implementation of regulation is seen as the panacea against the ever-pressing regulatory pressure on businesses. In finance it is even reported that today's "biggest question for bank controllers is how many humans they can replace with bots without compromising compliance" [83]. The idea of also automating the implementation of regulation certainly makes sense in order to keep pace with process automation and make appropriate use of the accumulation of large amounts of data. This development has led to a research focus in the field of business process security at the Department of Telematics of the Institute of Computer Science and Social Studies at the University of Freiburg. Related lectures, research projects, widely published articles and a range of doctoral theses also resulted in the development and publication of the Security Workflow Analysis Toolkit (SWAT) [9, 216]. SWAT is a tool for security analysis of business processes, providing methods for model- and log-based analyses and verification of security properties either from a preventive or a forensic point of view.

Automating regulation can still obstruct the execution of business processes, for instance, when there are no employees authorized to perform a pending process activity at hand. Hence, despite the many benefits of automation, the problem of regulation obstructing business is only shifted to the technical level. Regulation and its related concepts of governance provide ways how to resolve obstructions in order to support business operation. However, such solutions are not easy to find on a technical level. The problem here is that information technology (IT) security aims to remain in a secure state rather than allow the continuation of a business process.

In summary, if a business process violates higher societal or human rights, the process is illegal. Moreover, a business process could also support crime, for instance, money laundering. In both cases, law or regulation is supposed to be enforced in such a way that such processes are detected and stopped. However, as seen above, regulation can also disturb business processes, and its implementation can cause an unjust burden between the owners of the processes or their participants. The automation of the implementation of regulation can finally cause obstructions by inequality and costs. Thus, this thesis does not aim to avoid the legitimate interception of illegal activities but to harmonize the obstructive part of regulation and automated business processes in a security-sensitive way. Here, in particular, the conditions to detect and prevent obstructions in business processes will need to be identified.

This chapter aims to give an in-depth understanding on where these securityrelated obstructions come from and introduces the context in which to solve them. To motivate the need to automate the application of regulation and show its problems in terms of obstruction, the developments in fraud, regulation and towards process automation will be related in loose chronology to each other. In this way reasons will be identified why regulation acts obstructively and its application needs to be automated. Since big parts of regulation have indeed been automated on the infrastructure and application layer, the focus of this work will be on how to apply regulation on the business layer. It is the layer that allows for an aggregated view on activities that would otherwise appear isolated in the lower layers. In this way, dots can be connected so that fraud schemes can be revealed. In doing so, classic concepts of IT security will be introduced, which, however, can lead to such obstructions on the technical level. The way classic IT security handles obstructions here cannot work in processes, therefore the concept of indicator-based security will be introduced. Based on these findings, the section on the contribution and structure of the thesis will indicate how the problem of obstruction is tackled.

#### **1.1 Fraud in a Digitally Enabled World of Processes**

In retrospect, the 2007-08 financial crisis is often seen as the event that brought about today's plethora of regulatory and compliance measures. The following case of a European Bank involved in the financial crisis represents an exemplary reason for the drastic increase in regulation to fight illegal, criminal, or fraudulent processes after the crisis and also the huge effort and costs needed in solving the case: Roughly a decade after the global financial meltdown, in June 2018, the former CEO of the Anglo Irish Bank (AIB), David Drumm, was found guilty of dishonestly inflating the size of the bank's deposits by 7.2 billion Euro before its collapse and subsequent bail-out during the financial crisis. He was accused of conspiring to carry out the fraudulent transaction process with his former finance director, his former treasury department manager as well as the former CEO of the Irish Life and Permanent (IL&P) Bank, and others. These men were involved in setting up a circular scheme of billion Euro transactions in which AIB moved 1.2, 2 and 4 billion Euro to IL&P which then sent the money back via their assurance firm "Irish Life Assurance" to AIB (see Figure 1.1).

The scheme was designed in order to achieve that the deposits come from the assurance company such that they will be treated as customer deposits, which are considered a better measure of a bank's strength than inter-bank loans. Therefore, it acts as an indicator of the health of the bank, since such deposits show that corporate entities have faith in it [54, 102]. So, in the face of the financial crisis in fall 2008 and the end of the fiscal year on 30th September, the books were faked to mimic achievement of financial goals and palliate the state of the bank to still appear good enough to the government and the European Union (EU) in order to get financial support. Finally, apart from other related legal proceedings, the prosecution that led

**Figure 1.1** Sketch of how the Anglo "Back To Back" fraud process worked

to the imprisoning of the former CEO of the AIB cost 1.123 million Euro [72] and was one of the longest-running criminal trials in the history of the Irish State.

Still today, "statistics show that economic criminals are increasingly targeting businesses. However, businesses need to be aware that wrongdoing can also come from within." What the Irish Garda National Economic Crime Bureau conclusively stated on the AIB case is often connected to the notion of "white-collar crime"1. Indeed such crime or fraud within the operational procedures in enterprises recorded a tremendous increase in the last decades. Besides the AIB, the Swiss bank UBS suffered from a rogue trader scandal in 2011, which led to an estimated loss of 2 billion US Dollar. Earlier the French Société Générale had a loss of nearly 5 billion Euro caused by shuffling transactions. Similar constellations with inside perpetrators or internal attackers can also be seen in the fraud cases involving the WorldCom, Parmalat or Enron cases, or in more recent scandals, for instance, in the automotive industry or the financial technology industry (FinTech), for example, the "Dieselgate" or "Wirecard", respectively. Today's presence of fraud is drastically stressed by the 2018 fraud report of the Association of Certified Fraud Examiners

<sup>1</sup> Whereas in "corporate crime" the company or the corporation are beneficiaries, in "whitecollar crime" the individual involved benefits from its actions.

(ACFE), analyzing 2690 cases of occupational fraud that were investigated between January 2016 and October 2017. The total loss caused by the cases in the study exceeded 7.1 billion US Dollars, while these cases only represent a small fraction of the frauds committed against organizations worldwide during that time. The real cost of global fraud is probably significantly higher, especially when the indirect costs are considered, such as reputational harm and the loss of business during the aftermath of a scandal but also simply undetected or unreported frauds. Based on these limitations anti-fraud experts estimate that organizations worldwide lose on average 5% of their annual revenues to fraud (i.e., a total 4 Trillion US Dollars of the Gross World Product in 2017) [41].

One driver for this increase and ever-pressing issue of fraud is digitization. With the digital transformation, the risk of damage, its amount and the velocity of its growth significantly rise, which can be seen from growth in financial processes including private home banking. Clearly, fraud cases would also happen in an analog environment. Indeed, there are records of accounting fraud at Medici Bank dating back to the 15th century [131]. Nevertheless, the increase and size of recent scandals has, at least to some extent, made use of digital technologies, or were only made possible by them. Just by looking at the AIB case, the circular scheme's high frequency of transactions would not have been possible without the respective digital transaction systems. Even the exchange-traded fund transactions at UBS or the accumulation of transactions at Société Générale that operated directly below the risk threshold would not have been possible to such an extent in an analog system.

#### **1.1.1 Towards Process-Awareness and Process Automation**

On a positive side, however, digitization is the driver for comprehension and adaption of business in a process-oriented way. Information systems of organizations are moving more and more from a traditionally data-centric direction that supports business processes, towards a fully process-oriented view. This is because of the necessity to standardize procedures and adapt to changing environments in the course of globalization. The conception of standardized software for steering business processes follows this development. In general, a business process realizes business goals by orchestrating business activities in coordinated sequences. Process-orientation in software-systems already dates back to 1993 when SAP R/3 ERP-System adapted to a process-oriented view by introducing the Business Process Reference Model. However, no explicit control of the process was supported. Since the mid 90s, methods for process automation have created a series of systems, which supported the operation of business processes by an automated execution of partial steps and shaped the notion of "workflow management". Business process management (BPM) extends workflow concepts with a holistic view on processes in a business context. Workflow and BPM Systems can be subsumed under the notion of process-aware information systems (PAIS). A PAIS is a software system that manages and executes operational processes involving people, applications, and/or information sources on the basis of process models [3]. They include all software systems that support processes and not just isolated activities [82].

**Figure 1.2** Business process management lifecycle

While workflow management can be understood as a supporting technology, BPM is a process-oriented management discipline, which is based on the premise that efficient management and systematic process optimization contribute to the success of an enterprise. Thus, in addition to the (semi-)automated execution of processes, the entire process life-cycle is considered. Figure 1.2 illustrates its different phases. It starts with the specification that includes the modeling of planned process behavior, and contains the implementation in the system landscape of the enterprise, followed by process enactment as the phase in which the process is actually executed. It finalizes with the diagnosis to identify optimization potentials after execution. Along these phases, the process can be captured in different process entities, specifically, the process model, the process execution and the event log. As such, a process is executed by instantiating activities, whereas the resulting activity executions are coordinated. Activities are conducted sequentially or concurrently to each other; their execution is dependent on explicit decisions; and parts of a process may even be repeated multiple times.

The following example connects known facts of the AIB investigation to different process entities. Since IL&P was not willing to give unsecured loans because the cash limit of 100 Mio Euro was exceeded, they required a collateral to secure each loan. Therefore, AIB provided cash collateral that usually is safeguarded by several transactions. The involved process defines how a collateral evaluation for a secured

 a

loan is handled, with the outcome being the approval of the acquisition. A first activity is to determine the market value of the respective collateral. A decision is then made as to whether the value is correct. If it is correct, the acquisition of the collateral can be approved.

Figure 1.3 illustrates a process model that describes how a collateral evaluation in a financial institution is handled (based on the process description in [24]). It is executed to evaluate, accept, and prepare the safeguarding of the collateral that a borrower pledges in return for a secured loan and originates from the IBM Information Framework on Loans' process templates on the evaluation of collateral. This model, captured in the Business Process Model and Notation (BPMN), serves for illustration in the further course of this thesis. The execution of the process activities is coordinated within a specific scope, the so-called case. A case represents an instance of the process and is defined by all activity executions that refer to a particular trigger or input for the system whose behavior is described by the process. An event log fulfills the function of a business process tachograph. It records how the process is actually "lived". Once this process is supported by a PAIS, event data on the execution of this process is collected and may comprise information on the time a particular activity was executed for a case. The latter is related to a user, the requested amount, and the prospective duration of the loan deposit. Each collateral evaluation then represents a case, as part of which the activities of the process are executed. An example of such an event is given in Table 1.1.

Hence, processes capture the behavioral scope of an enterprise. Figure 1.4 sketches this scope of action. The points schematically symbolize the set of states of a PAIS resulting from performing its business activities, which can involve different users and data and belong to specific processes. The arcs represent these executions of business activities which change the system state. Hence, the arcs correspond to an event or a performed process activity and illustrate possible activity sequences. All combinations of activities, users and involved data are possible here. This could also involve fraudulent behavior.


**Table 1.1** Example event

#### **1.1.2 IT Security Applied on Processes**

Hence, in order to also use the potentials of digitization to secure such processes and combat fraud, computer security is applied on processes. Security in business processes represents an interdisciplinary field, which links security mechanisms from the security and business process management research communities [133]. Subsequently, security requirements on business processes are introduced, which allow to be enforced on business processes in an automated manner. Engineering secure processes is a multi-faceted problem, resulting from the different layers and services an enterprise contains. The architecture of an enterprise from an engineering perspective is captured with the so-called enterprise architecture metamodel [176], which can be used to characterize the level of abstraction a PAIS application exhibits [134]. This model divides the support of IT in modern enterprise system architectures in the subsequent inter-layers: The **infrastructure layer** provides the software and hardware needed to automate the execution of services or business processes respectively. This includes, for example, the required databases, the operating system, virtual machines and protocols (e.g. transport protocols, networks). On top of that, the **application layer** contains the services and data schemes that are required for the execution of the processes. In this context, service-oriented architectures (SOA) or higher service modes of Cloud and Grid computing are relevant. Although regulatory controls may be implemented on all three layers, such scenarios for the application layer and infrastructure layer have been investigated thoroughly and may be adapted and carried over to new architectures [153]. The upper **business layer** is the abstraction layer, containing business processes, which codify business goals and its process participants, the business objects and the assets of the company, as well as its organizational structure and guidelines to be followed. It allows for an aggregated view on the enterprise activities such that coherencies and interconnections can be identified, which is eminent for fraud prevention, e.g., to reveal fraudulent schemes. Enforcing the described subsequent notion of regulation and compliance can only be done and justified from this higher business level. Figure 1.5 relates these layers of the enterprise architecture to the unregulated business world, regulation, and its impact on security requirements.

Security requirements are standard principles to enforce security in information systems (IS). Hence, to secure business processes in a PAIS, the security requirements on the business level are subsequently deduced. IT security, or equivalently "computer security", is basically information security applied to technology. It is based on the three security requirements (tantamount to "security goals" or "protection goals"), which are confidentiality, integrity, and availability. "Control" in classic computer security is basically introduced by access control, consisting of

**Figure 1.4** Behavioral scope of (unregulated) business symbolized as a set of states (points) resulting from performed process activities (arcs)

authentication and authorization. An access control mechanism supports *confidentiality*. It restricts access by authorizing only certain subjects, such as people or (software) agents with the right to access the desired object. An object may be a file, a process or also a process task, activity or transaction. Before authorization, authentication is used to verify *integrity*, whether the subject is what or who it claims to be. Based on Gollmann, Figure 1.6 depicts this concept, in which a subject, here the *user*, requests access. After authentication, the reference monitor checks by means of the given access control list (ACL), if the requesting user is allowed to access

**Figure 1.5** Enterprise architecture layers and regulation

the desired object [98]. Besides ACL, a further common concept is the Role-Based Access Control (RBAC), which organizes users in groups with well-defined permissions, which is also represented in several NIST standards (cf. RBAC-Level-2 also including SoD). The basis for access control to function properly is, that the corresponding systems and mechanisms are *available*, such that there is no denial of service (DoS).

A security policy is a statement that partitions the states of a system into a set of authorized (secure) states and a set of unauthorized (no secure) states [33]. It considers all relevant aspects of confidentiality, integrity, and availability. Regarding fraud, unauthorized access may violate integrity. Security policies mostly define safety properties to "keep bad things from happening", for instance to avoid unauthorized access or that the same person performs two conflicting duties (SoD). In contrast, liveness properties try to "make good things happen", for example all duties can eventually be performed and required resources are available [13].

What is critical to security is the distinction between policy and mechanism. Whereas a security policy is a statement of what is and what is not allowed, a security mechanism is a method, tool, or procedure for enforcing a security policy (e.g., the introduced access control mechanism). Safety properties are typically enforceable, whereas liveness properties are not. Regulation may formulate rules or procedures addressing a range of different aspects and may concern monetary aspects or people authorized to perform specific transactions. To capture these different dimensions

**Figure 1.6** Access control = authentication + authorization

and its security requirements, a more fine grained view on processes need to be introduced as well.

The deduction of security requirements on the business process level is structured on the basis of different viewpoints on a business process, namely process aspects. These aspects are connected with security facets defined in several standards, e.g., the ITU-T Recommendation standard for communication security X.810 or ISO/IEC 15816:2002, among which are the more detailed requirements authentication, access control, non-repudiation, confidentiality, integrity, security audit and alarms, and key management, denial of service and availability [154]. Based on the work of Charfi and Mezini [42], relevant process aspects are fourfold. While the *behavioral and functional aspect* relates to causal and temporal relations between process activities together with structural compositions of processes (often named as the "control flow"), the *organizational aspect* considers organizational structures and process participants. The *informational aspect* is about the utilization of data and data flow in processes. Although these aspects are clearly separated by definition, security requirements often comprise several aspects at once.

Based on these aspects, related policies can be classified according to the subsequent general types [153]:


process cannot be carried out by a single subject. **Binding of duties** (BoD) characterizes the very opposite of separation of duties.

• **Isolation** generally says that information must remain confidential during the execution of a process. In other words, there is no information or data leak [11].

Literature of relates to workflows of business processes that encompass authorization and further constraints as "security-aware workflows".

#### **1.1.3 Security Requirements Obstructing Process Execution**

Given these classes of policies and the limitations of their enforceability (depending on whether they encode safety or liveness properties), security can be automated. However, Figure 1.7 partitions the entrepreneurial behavioral space into secure and non-secure states. It shows that the behavioral scope of automated implementation of regulation drastically restricts the behavior. This is because of the identified notion of classic IT security whose policies can only allow authorized and secure or nonsecure states of the process execution (the parts on compliance will be explained in detail in Section 1.2).

To illustrate this problem in more depth, the basic means against fraud, namely authorization and SoD, are applied. Figure 1.8 indicates such exceptional situation in a PAIS with authorization. It illustrates how the introduction of security requirements such as authorization and SoD are applied onto a business process and how even further environmental constraints, for example the absence of users due to illness or vacation, significantly minimize the set of users that are able to execute the process.

This may finally result in a situation during process enactment, in which no user is authorized to execute a pending activity; the workflow is obstructed. It is key to distinguish between workflow and the overall process here, since a workflow aims at the flow of the process activities, rather than considering all process aspects. Indeed, the obstruction is caused by the organizational process aspect that restricts user access to execute process activities and finally block the workflow. This represents an exceptional situation, in which the process execution, or the respective case, is obstructed because security constraints and user availability block further execution. The enactment or execution of a process becomes impossible because there is a lack of subjects who can execute the process activities and are authorized to do so at the same time. Hence, although the business process security requirements can be automated, their enforcement creates a new kind of obstruction. These requirements can obstruct acting in the behavioral scope of business set by corporate governance (compliant behavior). Figure 1.7 indicates such an obstruction by an arc crossing the

**Figure 1.7** Behavioral scope of IT security on processes

border between the secure and the compliant behavior (see obstruction arc), indicating that it would violate security requirements. More specifically, the obstruction arc actually escapes the obstruction. The obstructed state itself is represented by the state preceding the obstruction arc. Similar constellations can also be established with isolation or usage control policies, for example, if no user is available to close an open file. However, due to its common application (e.g., in internal controls), the focus of this work is on security-aware workflows that consider authorization and SoD or BoD constraints, which is sufficient to cause such obstructions.

Etymologically, obstruction means that someone or something is prevented from moving in the direction it is trying to go. The Latin word "obstruere" means blocking

**Figure 1.8** PAIS with policies and contextual influences

an access, to block up, to barricade, or building an obstacle. Interestingly, at the same time this means the object that is obstructed is not totally out of reach.

#### **1.2 Conventional Anti-Fraud Measures**

The introduction of IT security on processes can cause an obstruction on the technical level. However, this section shows that regulation itself does not necessarily create such obstructive situations or, if so, offers solutions or ways of circumventing them. This is due to the difference between the digital "world of correctness", which also embodies classic IT security, and the analog "real world" from which regulation originates (cf. Figure 1.5).

The basic solution to the problem of fraud is clearly that there is a legislation that defines laws and penalizes unwanted deceitful behavior. In Germany, for instance, which has a civil law system (like most of EU countries), fraud and related facts are codified in article 263 and the following of the criminal code (StGB §263 et seq.) that build the foundation for further regulation. On the other hand, U.S. law or further countries with Anglo-Saxon heritage like Ireland developed a law system that originates from the English common law, which is based on precedences.

In the AIB case, the CEO was convicted by unanimous verdict of the two offenses: first, conspiracy to defraud contrary to common law, secondly, false accounting contrary to section 10 of the Criminal Justice (Theft and Fraud Offenses) Act 2001 [16]. The latter consolidates the law relating to dishonesty, theft and fraud in Ireland. Hence, the definition of fraud in law is historically grown and depends on the legislative history of each country. Acts are understood as broad laws that are passed and the regulations are guidelines that dictate how the legal provisions of an act should be applied. Hence, the application of law is regulation.

#### **1.2.1 Post-9/11 and Post-Financial Crisis Regulation**

The financial crisis of 2007-08 especially underscores the importance of verifying that organizations operate "within their boundaries' [3]. Nowadays, enterprises have to face a continuously growing number of regulations and guidelines. Apart from the Basel Accords, which especially address banking regulations, the American federal statue SOX (Sarbanes-Oxley Act) of 2002 probably has the most significant impact. It requires an internal control system (ICS) for billing and external controllers to attest the effectiveness of the system, for example, to preserve the reliability of published financial data. The stir SOX has caused is evident by considering its worldwide adaptions, for example J-SOX (Japan), CLERP (Australia) or the EuroSOX (EU Directive 2006/43/EC on statutory audits of annual accounts and consolidated accounts). Moreover, international standards such as the ISO27k series of the International Organization for Standardization (ISO) have equivalents in SOX and vice versa. Regarding the AIB case, Irish legislation and regulation constantly adapted to the requirements arising from the financial crisis [147]. The offence of intentional falsification of accounts is also captured in EU market-abuse rules (with penalties up to ten years in prison and a fine of up to 10 million Euro) or the American Code of Laws (18 USC Sec. 1005, with penalties up to 30 years in prison and a fine of up to 1 million Dollar). One of the currently most prominently debated regulations is the General Data Protection Law of the European Union (GDPR), which came into force in 2018. It also emphasizes the need for companies to be able to demonstrate compliance with accountability and further principles regarding the handling of information. Enterprises, such as banks, have the duty to act upon these regulations and the governing law relevant in their economic areas and legal space. This means that they also have the duty to take action for themselves to adhere to regulation and ensure that there is no violation of it. They need to integrate it into the way they lead and control their operations. Otherwise, legal action may be taken. In this respect, the increasing regulatory pressure in finance can be stressed as regulators have fined financial firms at least 28.4 billion Dollars for money-laundering and sanctions violations since 2008 and another 9.5 billion Dollars for aiding tax evaders.

Looking at the fraudsters in an enterprise, the ACFE identifies three main aspects that influence a potential perpetrator:


Certainly, entrepreneurial measures, for instance fair and proper salaries and a good code of conduct, may lessen financial pressure, strengthen ethics in a company and may make rationalization harder. These two aspects are mainly based on situational or personal reasons. However, the "opportunity" to commit fraud, underlines the need for regulation and its effective implementation in enterprises to establish enough measures and control such that the opportunity to commit fraud is ruled out or at least minimized. Hence, since corporate fraud takes place in the enterprise, regulation provides the following general concepts and controlling functions in business under the overall roof and concept of corporate governance.

#### **1.2.2 Corporate Governance**

**Governance** unifies the regulatory concepts on the entrepreneurial side and sets the frame how fraud measures are established in order to still support business operation. As identified, enterprises not only have an intrinsic interest in security to prevent fraud, but also an extrinsic motivation by given law and regulation. However, enterprises are also keen to comply with accepted standards in industry so they can claim to be compliant. Hence, besides implementing regulation and standards, organizations want to protect themselves and may profit by going beyond what is only "necessary" or "required from outside".

**Figure 1.9** Compliance as part of corporate governance

Based on Schröder et al. [185], Figure 1.9 shows the bigger context in which subsequently elaborated components can be put, namely corporate governance. In general, corporate governance defines how enterprises and specifically processes are conducted in terms of leadership and control. It is the combination of culture, policies, processes, laws, and institutions that define the structure by which the organization is directed and managed. Compliance management, risk management and the system of internal controls build the three pillars of corporate governance, which aims at an successful supervision of an enterprise. These three pillars are monitored by the board of directors as the senior supervisory body [130]. Moreover, corporate governance requires the board to also establish an audit committee to review and assess the effectiveness of the internal control system, including financial reporting, but also risk and compliance management.

**Internal Control Systems** play an important role for fraud prevention. The U.S. Committee of Sponsoring Organizations of the Treadway Commission (COSO), which became renowned especially in the course of the SOX, defines: "Internal control is a process — effected by an entity's board of directors, management, and other personnel — designed to provide reasonable assurance regarding the achievement of objectives in the following categories: (a) reliability of financial reporting, (b) effectiveness and efficiency of operations, and (c) compliance with applicable laws and regulations." An important component of internal control is the control activities. They represent the specific policies and procedures that shall be applied on or extend business processes. Here, the ACFE report's set of guidelining questions stresses the procedures and practices of internal control that are key against fraud, indicating especially the importance of authorization and SoD principles2.

The essence of each regulation, the legal semantics of law, is decided through the courts, where regulation goes from theoretical legislation to practical rules for running an enterprise. **Compliance** means the fulfillment of such rules and obligations, resulting from law and regulation, but also guidelines, norms or corporate governance. Compliance rules initiate the respective policies and procedures resulting from internal controls. For instance, an SoD rule initiates the respective SoD control activity. Regarding the origin of these rules, the "Code of practice for information security controls" from the ISO 27002 standard postulates that it is essential that an organization identifies its security requirements. More specifically, this concerns "the legal, statutory, regulatory and contractual requirements that an organization, its trading partners, contractors and service providers have to satisfy, and their socio-cultural environment." As with all regulation and compliance requirements, this underlines that organizational compliance is not considered to be an objective, impartial measure. In contrast, it is rather influenced or even biased by different stakeholders, economic interests and, more generally, politics and stems from the context or socio-cultural environment in which the law has evolved.

To assess how to handle the danger of fraud with controls, risk assessment is key. Trust, the (brand) reputation, shareholder value, regulatory compliance (fines, jail time), customer retention, privacy, staff morale or the ability to offer and fulfill business transactions are crucial factors which can be at risk for an enterprise. **Risk** is commonly understood as the product of the occurrence probability and the impact (or damage) of a given event. The ISO 27002 standard requires "the assessment of risks to the organization, taking into account the organization's overall business strategy and objectives." Moreover, "through a risk assessment, threats to assets are identified, vulnerability to and likelihood of occurrence is evaluated and potential impact is estimated." Identified risk may be accepted (based on minor probability of occurrence or low expected damage), outsourced (for instance by insurance) or handled otherwise. Handled risks are relevant for the system of internal controls. An adequate control to reduce the probability of the risk to occur has to be implemented here, for instance, by adding a respective control activity to a process. The calculation of risks can be done with different methods, such as the failure mode and effects analysis (FMEA).

**Auditing** has the aim to evaluate enterprises and their processes. Audits are carried out to ascertain the validity and reliability of information about these

<sup>2</sup> Other measures identified therein such as job rotations and vacations finally also aim at the change of duties.

companies and the associated processes. In this way, it is checked whether the execution of business processes is done within certain boundaries set by managers, governments and other interest groups and stakeholders. Specific rules can be enforced by law or company policies, and the auditor should check whether those rules are being followed or not. Violations of these rules can indicate fraud, misconduct, risk and inefficiency.

**Figure 1.10** Behavioral scope of enterprise bounded by regulation (circle)

Given the concepts of regulation, the behavioral possibilities of an enterprise can be divided into compliant (see the area within the circle in Figure 1.10) and non-compliant behavior. Figure 1.10 indicates this behavioral scope restricted by regulation and complements the explanation on Figure 1.7. Thus, an arc crossing the respective border represents a non-compliant business activity. The German financial regulator, the Federal Financial Supervisory Authority (BaFin), for example, expressly requires the separation of duties in scenarios such as the approval of a loan deposit, for example between activities for calculating and controlling the market value, because assets are affected (cf. IAA SoD Definition). Hence, performing this activity by the same person would represent non-compliant behavior (indicated as arcs crossing the circle). As indicated before, the area of secure behavior is indicated in Figure 1.7. Each obstruction arc indicates a part of a process execution here, in which IT security would block the process execution, whereas corporate governance would allow a solution to continue process in the scope of compliant behavior. Hence, from a compliance perspective, in such an obstruction the process can still be completed by a rational decision, balancing the potential harms of neglecting security against missing the business goals. Hence, an obstruction is the point in the process execution when a decision has to be made whether to stop the process execution or to find a solution based on regulation, risk, and corporate governance to still complete the execution. The frame set for such a solution on the business level is set by corporate governance; it is not about security.

#### **1.2.3 The Need to Support Regulation by Automation**

Despite the concepts of regulation to restrict the scope of behavior to avoid fraud, their implementation in businesses is deficient. In other words, the indicated boundary in Figure 1.10 between compliance and non-compliant behavior often does not exist in practice because the intended compliant behavioral scope is often not adequately implemented and controlled. In this respect, the ACFE report states that internal control weaknesses were responsible for nearly half of the frauds that were investigated. In particular, survey respondents were asked for their perspective on the internal control weaknesses at the victim organization that contributed to the fraudster's ability to perpetrate the fraud scheme. More than 30 percent cited a clear lack of internal controls as the primary issue, another 19 percent stating that internal controls were present but had been overridden by the perpetrator. Here, overriding may set a so called "red flag" indicating a potential suspicious fact for further fraud investigation. In this respect, management review describes the process of management reviewing organizational controls, processes, accounts, or transactions for adherence to company policies and expectations. The other half is led by another 18 percent that were owed to a lack of such management review.

To some extent, this overall lack and override of control and the missing review can be all attributable to the obstructive nature of the implementation and enforcement of regulation in practice. Here, one can differentiate between enforcement from outside the enterprise (e.g., high efforts and costs of law enforcement in the AIB case) or inside the enterprise (e.g., internal audit). The likelihood of regulation obstructing business is even growing with the ongoing digitization. Whereas business processes are more and more automated, regulation is often not. Regulation is frequently still conducted manually or is only partially computer-supported. According to the ACFE, only one percent of the detected fraud is initially detected by IT controls. The majority of fraud schemes is revealed by hints (40 percent), internal audit (15 percent) and management review (13 percent). In practice, internal auditing teams can obstruct operational business for month [92]. Traditionally, auditors can only provide reasonable assurance (cf. ICS) that business processes will be conducted within the specified boundaries. Based on the aims of internal control, they check the controls' operative effectiveness designed to ensure and maintain reliable processing. If these controls are not in place or otherwise do not work as expected, they typically only check samples of factual data, often in the "paper world" [3]. In this way, they are not able to completely check all relevant process data and therefore do not provide the full picture, such that suspicious activities may not be detected. In automated processes, the manual application of regulation intervenes even more drastically in the otherwise automated business operations. Today, event logs or audit trails, transaction logs, databases or data warehouses record detailed information about processes such that implementations of processes produce event logs of considerable size in practice. For example, around 10,000 loan applications were submitted to a major European bank over a period of 6 months. Because the resulting event log contains more than 200,000 events, a manual analysis of the respective data is no longer possible [40]. Moreover, as the ACFE results propose, the huge amounts of data provided by automation are not adequately used in manual checks. Hence, in the face of process automation, manual fraud controls are too slow, obstructive or simply missing.

The fullness of today's regulation, automated processes and big data demands the automation of the implementation of regulation in order to use the potentials that lie in automation, for instance to digest all necessary process data. To speed up its application and counteract its obstructive behavior in terms of delaying business operation and demanding high monetary and temporal effort, the logical and necessary step is to automate regulation that acts upon the business processes as well.

#### **1.3 Obstruction by Security?**

Despite the deficits identified in the application of IT security on processes, in particular the appearance of obstructions at the technical level (see Section 1.1.3), there is a need for automation of regulation. Because the behavioral space of corporate governance permits more behavior than that of IT security, this should also be taken into account in the automation of regulation.

#### **1.3.1 The Dilemma of Process Security in Following upper Policies**

IT security originates from controlling access over data, not process-oriented activities. For instance, if access to data in a database has an error, the transaction is rolled-back. In contrast, unlike in database transaction processing, security policies in processes may not be fully checked before granting access, due to missing information of other related processes such as inter-instance process dependencies or further context specific data, such as user availability. Regarding databases, the ACID criteria (atomicity, consistency, isolation and durability) are not applicable for such long-lived transactions like a business process. Although there are even scenarios and also concepts in transaction processing of rolling back long-lived transactions, this cannot be in the interest of a business process execution.

In analogy to this and the need for a business process to run through, a short excursus is given by means of an example from sports. Since 2018, there has been a video referee at the Tour de France, the Spanish Vuelta and other famous cycle races who can intervene retrospectively. This video commissioner has access to all cameras and can review and evaluate any situation at any time, rewind, zoom in and assess if a first suspicion is justified, for example a rider pushes a rival aside. Of course, you cannot stop the race at the Tour de France. Consequences can only be taken after the race; after crossing the finish line. Then, a team of race control and referees looks at the respective selected material and then, it has to decide what to do. Hence, during the race there is only a suspicion. After the race, the decision is made and consequences can be taken. Ideally, one would like prompt, binding decisions here. Analogously, business processes need to operate and only after "crossing the finish line" or reaching the process goal can the security be fully assessed. However, if there is a problem, one would like to promptly identify it and act accordingly. This could mean to change the process or take further steps after an identified violation. This could clearly also mean that damage already occurred, if for example payments have already been done during the process.

Based on these considerations, the assumption security is based on changes. Indeed security in business processes should not only consider the protection of objects like in classic computer security but also take upper policies set by corporate governance into account. This represents a paradigm shift; moving away from trying to achieve or sustain protection goals, such as confidentiality and integrity, or simply "keeping bad things from happening" towards an end-oriented view on security in business processes where not so much a violation of security is a problem but at the end a compliant result must exist to eventually "make good things happen". Hence, whereas classic security stresses the safety property, business process security emphasizes the liveness property.

#### **1.3.2 Indicator-Based Process Security**

Altogether, the classic understanding of security does not fully apply to the context of business processes. The concept of classic security clearly builds the essential basis for business process security. However, based on the identified reasons, this so far policy-based classic security concept needs to be extended. Common ways of compliance management to resolve obstructive situations are setting red flags or delegation. If there is an obstruction due to an SoD conflict imposed by regulation, it is possible to assign substitutes that do not have the managerial level of the initial assigned users. Then, the delegator indicates an appropriate substitute based on his risk assessment of the delegatee. This represents a compliant solution to resolve an obstruction, for example based on the BaFin regulation (Finanzdienstleistungsaufsicht [94]). Considering best practices of internal auditors, it is a wellknown means to set red flags for fraud, for instance when a control is overridden due to an obstruction. Red flags are signs that indicate both the inadequacy of controls in place to deter fraud — in the sense of not being effective but also in obstructing the process — and the possibility that some perpetrator has already overcome these weak or absent controls to commit fraud. These indicators can then be used for detection and prevention and ultimately aim to lessen the risk of the execution of business processes. Hence, indicators allow to reduce the risk of a fraud to happen and at the same time support the completion of the process. This can also be stressed by looking at the etymological meanings of the respective concepts. Etymologically, "to comply" means to fulfill something and originates from completing (lat. complere), i.e., bringing something to its very end. Also the conformity to rules is often named equally to compliance, meaning to be in accordance or strong similarity to something. This notion generally is less strict than the meaning of security, originating from the Latin terms "se-" (engl. without) "cura" (engl. care) and can be translated as "free of care". In the literal sense, the inherent goal of security is to accomplish a carefree state, i.e., to avoid a state that may cause worries. Hence, whereas security literally tries to avoid risk, compliance tries to keep given rules while allowing to take a certain amount of risk and worries into account to fulfill the overall goal of completion (or "bringing it to its very end").

Due to the limitations of classic security in processes, the policy-based security concept is supposed to be enhanced with an indicator-based view, thereby allowing to better represent and capture the frame set by corporate governance. The area of secure behavior is supposed to be widened towards the compliant behavior (or shifting the respective border in Figure 1.7). Using indicators in business processes is not uncommon, for example Process Performance Indicators (PPI) or Resource-Behavior-Indicators (RBI). The focus of this work is to use indicators in order to find a security-sensitive solution to obstructions.

Table 1.2 displays different works in the Business Process Security Group in Freiburg that contribute to this perspective on security. For instance, Lowis analyzes compliance based on given rules and workflow models. Stocker [189] provides a way how to reconstruct process models from event logs that are able to indicate rare deviating suspicious behavior. Moreover, Zahoransky [215] uses simulation to investigate if control activities imposed on single core processes are a problem in performance in the context of entire business process architectures (cf. PPI). Syring [193] defines a framework how to decode legal code into (semi-)formal rule that are machine-readable and can be applied in an indicator-based way. Wonnemann [214] proposes a way to check (unwanted) flow of information based on models. All these approaches aim to automate the implementation of regulation to some extent. However, they have so far not addressed the problem of runtime obstructions during process enactment in processes and its practical consequences and how this conflict between business and security goals should be handled.


**Table 1.2** Comparison of Freiburg approaches addressing security before, during and after process execution: addressed, (-) partially addressed, ✗ not addressed

#### **1.4 Contribution and Structure of Thesis**

Automation is no panacea against regulation acting obstructive. Adequate and effective application of regulation builds the basis against fraud. However, there is no way to avoid automation when IT methods are used to generate competitive advantages. An obstruction results from introducing IT security on business processes, particularly authorization and further security policies such as separation of duties. Handling situations that obstruct the business process are key, because, besides the business harm, not handling them in an automated manner would contradict the overall intention of automating security to speed up the secured process. Hence, the aim of this thesis is to specify obstructions on a technical level and provide automated security-sensitive solutions that take the frame set by cooperate governance into account. By learning from obstruction handling in corporate governance, indicators are identified and an indicator-based security is proposed, which allows to benefit from process automation and process event data. In detail, this dissertation provides the following contributions 3:


Figure 1.11 shows the structure of this work. Chapter 2 examines the state of the art with regard to security-related obstructability in PAIS, such as workflow sat-

<sup>3</sup> Parts of this work (in particular, with regard to the identification of the research field, the basic approach idea of how to detect, capture, and resolve obstructions, and the tools used) have been published and can be found in [9, 106–109, 216].

isfiability and resilience. Thereby, requirements for analyzing, detecting, and handling obstructions will be derived along the phases resulting from the enforcement of security properties and the BPM lifecycle. Besides introducing the notion of "obstructability" and "completability" of security-aware workflows, various possibilities of how, in particular, logs can be used to obtain indicators will be examined.

**Figure 1.11** Structure of thesis

Chapter 3 builds the central part of the thesis. In addressing the requirements for obstructability analysis (ROA), it is primarily concerned with the modeling of obstructions in security-aware workflows. For this, it will first explore the ways to model processes, in particular, the modeling of the control flow. Based on the selection of an ordinary Petri net model (P/T net) as the method of modeling, a security-aware Petri net representation, the SecANet, will be developed. The general idea of the SecANet modeling is to "flatten" the organizational aspect of a security-aware process specification that subsumes the process model and the policy specification into the model representing the functional and behavioral aspects. That way, a so-called "obstruction marking" can identify and capture obstructions. Moreover, indicators can be assigned to the task- and policy-related Petri net elements as costs. For the evaluation of the SecANet approach, its Petri netspecific properties will be investigated. Moreover, the formal correctness of the SecANet method will be proven by examining the behavioral preservation of the original inputs (i.e., language preservation). To take cyclic workflow behavior into account, the concept of policy re-enactment will add cyclic functionality to the so-far acyclic SecANet encoding. The developed SecANet formalism can be regarded as a target metamodel of security-aware process specifications that creates a basis for further analysis. Accordingly, Section 3.2.6 will subsume SecANet-based satisfiability and obstructability checks as SecANet soundness and show further extensions to facilitate analysis. An experimental evaluation will compare soundness checking runtimes with typical satisfiability-related approaches. The discussion will then examine the computational complexity of the SecANet encoding and sketch possibilities for extensions. With the introduction of SecANet+, the integration of additional inputs that further constrain the execution of tasks, for instance, counting constraints or user absence (resilience), will be made possible. Chapters 4 and 5 will use the SecANet encoding to handle and resolve obstructions. Across all these chapters dealing with approaches and solutions within the described problem context, the security-sensitive costing will play a crucial role in enabling the consideration of indicators. In order to address the requirements for specification-based completability (RSC), Chapter 4 proposes a model-based technique to complete obstructions. Thereby, the OLive-M approach will interpret the question how to complete an obstructed process as an optimization problem. Based on the examination of suitable methods, an integer linear programming model that optimizes the SecANet marking equation and its security-sensitive costs will realize the OLive-M approach as a way to deal with obstructions. In contrast to the exhaustive exploration of all possible markings (i.e., computing the marking graph), the experimental evaluation will underline the "lightness" of this technique to resolve obstructions. The discussion will then indicate how the approach can be used to also analyze satisfiability or resilience. Chapter 5 focuses on log-based completability (RLC) and considers the obstruction as an execution trace in the context of process event logs. The realization of the OLive-L approach will incorporate methods of process mining and machine learning techniques to propose solutions that represent the nearest match of successful executions to escape an obstructed state. To show the applicability of the OLive-L approach, the evaluation offers experimental results based on event data synthesized from SecANet execution sequences. In the course of the discussion it will be sketched how logs may be used for the model-based approach and vice versa.

Chapter 6 summarizes the work and explains its significance by considering the contributions and its applicability. The work concludes with extensions that could be envisaged.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **2 Security-Related Obstructability in Process-Aware Information Systems**

"The practicality of any security policy depends on whether that policy is enforceable and at what cost [182]." What Schneider stated in his seminal work on enforceable security policies also applies to the conflict between security and business goals in business processes. In classic IT security, enforcement mechanisms work by monitoring execution steps of some system, often called the target, and terminating the target's execution if it is about to violate the security policy being enforced. In order to operate a Process-Aware Information System (PAIS) according to given policies, mechanisms that implement the policies and control their enforcement are equally necessary. However, if such mechanisms are used in a PAIS, this is opposed to the achievement of business goals, as enforcement may "cost" the completion of the process execution, such that the process does not generate the expected value to the company. Technically, it is this enforceability that enables the process execution to become obstructed. Hence, an obstruction is the case when enforceable policies conflict with the goal of process completion, or, put differently, enforceability implies obstructability. The first chapter identified that detecting, preventing and handling the obstructability resulting from the implementation of an automated regulation, is an important problem. It showed that a solution must provide an indicator-based view on security that enables obstructed executions to be completed. In this respect, the concepts of governance, risk and compliance allow for greater room for maneuver than classic IT-security and should be considered when solving obstructions. The actual costs of enforcement may therefore take into account not only the financial loss due to process stop but also the risks if the process is nevertheless completed, for example if tasks are delegated, executed by unauthorized users or if SoD rules are violated. Based on such considerations a rational decision has to be taken whether and how to continue the process or to stop, or, in relation to Schneider, to balance enforcement and its costs.

This chapter aims to relate this conflict to the existing state of the art. It will therefore first introduce concepts related to security properties and their enforcement to better grasp the problem of security-related obstructability in PAISs. Based on this and the BPM lifecycle, a structure will be derived along which the analysis of related work will then be conducted.

**Figure 2.1** Obstructive sequence of activities

To begin with, it can be observed that the identified conflict between security and business goals occurs on the level of a single process execution that eventually becomes obstructed or runs through. Figure 2.1 exemplarily highlights an activity sequence of such a single execution, based on the executions encoded in the representation of the behavioral scope of a process in a PAIS. Based on the introduced behavioral areas of a process in Chapter 1, the sequence encompasses activities in the scope of secure behavior (the first three activities) and in the scope of compliant behavior (the last three activities). Moreover, there is an activity (the forth activity) that escapes the obstructed state (indicated as a barricade sign). Hence, the representation of the obstructive activity execution provided in Figure 2.1, embodies secure behavior, which would actually not allow to complete the execution of the process securely and would therefore cause the PAIS to block further execution. However, it also contains the complete successful execution that is enabled by escaping the obstruction in a still compliant way. In relation to the BPM lifecycle, such an activity sequence can be determined on the basis of the process specification as a task execution sequence. It occurs during runtime in a case, or can also be found in logs as a so-called trace.

The conflict between security and continuity in operation is not new but it now manifests itself no longer at the infrastructure or application level but at the business level, which involves the business processes, regulatory rules implemented in PAISs and the process stakeholders. The basic security concept that can be applied to these architectural layers was first introduced in the context of language-based security (LBS [183]) by so-called security **property** classes focusing on the application layer. Because a process can also be seen as a small application—in fact, a workflow can be understood as a business process representation on the application layer—this view is adaptable to the business layer as well, which manifests itself in the common notion of an execution sequence or, equivalently, a trace for both layers. In order to be able to reason on whether system states satisfy specific security requirements, the notion of "properties" is used. The focus on these properties is supposed to help to reason on their impact on the process execution and the desired outcomes for the detection and handling of obstructions throughout this chapter.

The notion of trace properties can be used to specify basic types of security classes. Because it will be sufficient for the subsequent analysis of the state of the art to informally show the general concepts and intuitions, it is referred to a more formal definition of properties and the related property classes to the seminal works of Lamport, Alpern and Schneider in this field [13, 132, 182]. Informally, a property itself is encoded by a set of execution sequences. Such trace represents an execution of an abstracted system as a sequence of events. The observation of these execution sequences allows to reason on their properties, such that traces can be identified for which a specific property holds. In other words, the set of sequences that hold this property, builds a subset of the set of all sequences. As introduced in Chapter 1, there are two basic property classes, namely safety and liveness. A **safety** property stipulates that no "bad thing", i.e., the violation of a property, happens during the execution [13]. It describes states that should never be reached. This means, if there is a certain sequence that can be appended to a given execution sequence, such that the property does not hold anymore, it is a safety property. There is a finite prefix in the execution sequence at which the violation can be detected (discreteness)1. Typical safety properties are confidentiality or integrity (keeping a private key secret or mutual exclusion). If a violation of the property happens in an execution sequence, this execution can then not be remedied for this property or, in other words, there is no chance to fix it. Hence, for safety considerations, partial sequences are sufficient and, if a safety property is violated, this happens in finite interval of time. For example, suppose the safety property that the two activities "compute market value" and "control market value" shall be executed by

<sup>1</sup> A safety property can be proved using an invariance argument [14].

different people. If there is a sequence in which both activities are performed by the same person, this sequence does not hold the safety property anymore. On the other hand, a **liveness** property, as introduced by Alpern et al. [13], stipulates that a "good thing", i.e., the fulfillment of a property, eventually happens during the execution. Typical liveness properties relate to availability, for example, guaranteed service, starvation freedom (i.e., a process makes continuous progress) or process termination. This means, if there is a certain sequence that can be appended to a given execution sequence, such that the property holds, it is a liveness property. A liveness property cannot stipulate that a "good thing" always happens, only that it *eventually* happens2. Unlike safety, liveness does not require the "good thing" to be discrete. It refers to states that must be reached at some time in the future, and it means that something good will happen sometime. In other words, it is always possible that the "good thing" will still take place and it is not sufficient to consider partial sequences to assess liveness. Given, for example, a partial execution of the collateral evaluation process where a user has not (yet) executed the activity "approved acquisition", it is always possible to extend a partial sequence in a way that a user executes the activity by appending a sequence with this activity to the existing sequence.

In relation to the identified activity sequence in Figure 2.1, Figure 2.2 sketches a liveness property, in particular the reaching of the end activity, and a safety property, in particular an existing SoD constraint between two events (or activity executions respectively). It depicts that, for a partial trace (here, the first three events) the safety property holds. In contrast, the liveness property holds for the whole execution sequence. In this way, it is now possible to capture secure and compliant behavior with the respective property classes.

**Figure 2.2** Intuitive example of property classificiation for an obstructive sequence

<sup>2</sup> A liveness property can be proved using a well-foundedness argument [14].

The differentiation between safety and liveness has further implications. Depending on the property class to which a property belongs, it can be enforced, such that the violation of the property can be prevented, which means the execution of the target system to which it applies, is stopped [14]. As it is this enforcement and its implications that cause the occurrence of obstructions, a closer look at the respective enforcement mechanisms is followed. This step will enable a better insight into the causes, time-points and forms in which obstructions can manifest themselves.

Schneider showed that only safety properties are enforceable whereas liveness properties are not [182]. Mechanisms to enforce safety properties are classically divided into static analysis, execution monitoring and program rewriting [103]. Schneider describes static analysis as an enforcement mechanism that strictly operates prior to running the untrusted program. The idea of static analysis is that, after the analysis, accepted programs are permitted to run unhindered while rejected programs are not allowed to run at all. Reference monitors [15, 210] and other enforcement mechanisms that operate alongside an untrusted program are termed execution monitors [182]. Program rewriting refers to any enforcement mechanism that, in a finite interval of time, modifies an untrusted program prior to execution. This chronological differentiation may be well-applied on the business layer as well. Instead of programs, the object to investigate are processes. Analogously, depending on the time of enforcement, the policies that can actually be enforced, differ. For instance, a separation of duties constraint, which depends on the actual execution history of a process instance (also known as "dynamic SoD"), can only be enforced at runtime. If the set of executions for a security policy is not a safety property, an enforcement mechanism for the class of properties an execution monitor can enforce does not exist. On the other hand, the converse—that all safety properties have enforcement mechanisms for execution monitoring—does not hold (for example for the Maximum Waiting Time (MWT) regarding time interval) [182]. In this respect, Schneider already identified that his conditions for enforceability are necessary but not sufficient. To address this, based on similar monitors that observe system actions and terminate systems to prevent policy violations, Basin et al. [26] distinguish between actions that are only observable and those that are also controllable. Their enforcement mechanism cannot terminate the target system when considering an only observable action. In contrast, it can prevent the execution of a controllable action by terminating the system [26]. However, because the only observable cases are rather encompassing policies related to time, for example meeting deadlines, or administrative changes, such only observable policies will not be in focus of this thesis. In fact, it is the cases of controllable policies that may obstruct executions. Therefore, it is sufficient to stay with the basic notion of enforceability given by Schneider. The terms of Basin et al., however, are occasionally used for clarification. In this respect, the enforcement of any enforceable safety property can lead to an obstruction, because, in order to avoid a violation a reference monitor per se is always able to block an execution. In this thesis, this obstructability is considered for those enforceable safety properties that are relevant with regard to the security requirements for business processes identified in Chapter 1.

According to the points of time of an enforcement mechanism, enforcement of security properties from a purely chronological point of view only makes sense by means of a preceding preventive analysis before the execution, or monitoring during the execution. After the execution, the result of it must be accepted as it is and properties can not be actively enforced anymore nor change the status quo. However, narrowing the focus only on the phases relevant to enforcement would neglect a significant portion of the possibilities offered by process logs. A log allows to check for safety and liveness properties, and this, for the actually "lived", thus practically relevant processes. More specifically, the log is also the only way to check whether processes have really been completed in practice, in other words, whether the possibility of completion, the desired liveness property, was actually perceived in the process being performed. Hence, for a holistic detection and handling of obstructions, all three phases of the process execution are important. Then, depending on the regarded process entity, there are different possibilities to treat or avoid potential damage resulting from obstructions: Before the execution, the design of involved processes can be addressed. During the execution, runtime monitors are in control and obstructive situations can be detected and handled, and after the execution, damage may already have occurred but can be determined, for example, by auditing, such that its effects can be mitigated subsequently. Further, the log can also be used to learn for the handling of obstructions based on the history of the process.

**Figure 2.3** Properties encoding the cause of obstruction (safety) and the desired outcome (liveness)

In conclusion, before, during and after the process execution different aspects of safety and liveness manifest themselves. Figure 2.3 abstracts from specific obstructive activity sequences and depicts how these complementary property classes set the frame to analyze and handle obstructions. In a sense, these classes capture the cause and the cure for obstructions at the same time. On the one hand, enforceable safety properties cause obstructions. Their consideration allows to reason on the detection and avoidance of obstructions and how policies may be improved. On the other hand, liveness encodes the property of process completion, which describes the aim to escape and resolve an obstruction. Their consideration allows to find out when obstructions occur, that is when the liveness property is not fulfilled (falsification), or when there are no obstructions, which can give hints on how obstructions can be fixed.

**Figure 2.4** Terminology of processes, event logs, and models [40]

Based on Figure 2.4, Table 2.1 relates the identified different kinds of enforcement and security perspectives to the BPM lifecycle and its process entities. Preventive and detective mechanisms [33] work on the process model or the log respectively. Execution monitoring observes the process instance at runtime. Based on this structure, the subsequent systematic analysis of the state of the art determines deficits and potentials for development for the detection and treatment of obstructions, which then lead to their reformulation in the form of requirements, which a solution should consider, with regards to the goal of this thesis: to escape an obstructive situation that was caused by a safety property and find a solution that restores liveness, that is, to allow for process completion. In all of this, the common terminology and policies, problem cases and developments in the related fields will be grasped, such that they can be applied and adapted or that they can inspire solutions to obstructability. The requirements for the three approaches of this thesis will be derived from the three individual areas arranged according to design, execution and audit time. Firstly, the analysis of the state of the art for preventive analysis will determine the requirements for a specification of a model that covers all relevant process aspects and can be of added value in practice. Based on this, the requirements from execution monitoring will then be identified for the approach to resolve obstructions. Finally, with the analysis of log-based approaches and its potentials regarding obstructability, the basis is laid to beneficially involve logs to identify and resolve obstructions.


**Table 2.1** Process terminology from Figure 2.4 [40] related to BPM lifecycle phases and enforcement mechanisms

#### **2.1 Preventive Process Analysis: Obstructability by Design**

The preventive analysis takes place prior to the actual process execution and is related to the "Design" and "Analysis" phase of the BPM lifecycle. The idea here is to first analyze the effects of policy enforcement a priori execution to find out, if the process is obstructable. For this, this subchapter will first consider the process specification, which embodies the different process aspects. Based on the process model and the process policy, it will be shown that obstructability foremost analyzes possible conflicts between the organizational and the functional and behavioral aspect of the process, namely if there is a user-task assignment that is able to obstruct the execution of the control-flow. This question relates to other questions that arise with the enforcement of policies in security-aware workflows, more specifically, questions regarding their satisfiability and resilience. The so-called workflow satisfiability problem (WSP) asks whether there is a mapping of users to tasks in a workflow so that each task can be executed and the policy can be followed. Moreover, obstructive situations may also arise due to reasons beyond the policy. For instance, if there are exceptional situations due to illness of staff or further unexpected unavailabilities. The notion of resilience (or resiliency) is used to describe such scenarios, asking how many users can be absent (or are likely to be absent) such that the policy can still be followed and each task is still executable. To some extent, WSP and resilience analysis imply obstructability analyses. For example, an unsatisfiable workflow is obstructable as well. However, a satisfiable workflow can still contain obstructions. The particular differences of these notions will be elaborated in more detail in the subsequent sections. Due to this interrelation, and to allow for comparability, this subchapter will mainly elaborate on satisfiability and resilience problems, which will sometimes implicitly relate to obstructability analysis as well. However, it will also reveal that, so far, explicitly analyzing obstructability has only marginally been considered in related work. The sections on satisfiability and resilience will therefore highlight important findings and deficits from related research and extract criteria that will be key for the preventive analysis of obstructability.

#### **2.1.1 Process Specification**

The design of the process manifests itself in its overall specification, because a PAIS is steered by the process specification. It builds the basic reference to preventively analyze policy enforcement in a PAIS. However, strictly speaking, because the term "process specification" is often intended to only describe the control-flow, it does not represent the whole process. Rather, there are different specifications that encode different parts of the different process aspects, which were briefly introduced in Chapter 1.

The process model is typically used to capture the functional and behavioral aspects of the process. In particular, it specifies the control flow to capture the behavior and includes the functional components of the process, for example in the Business Process Model and Notation (BPMN) language (which is used for the example in Figure 1.3). This overall composition encodes the business goal, which is a central part of the functional aspect.

For the other aspects, in particular for the organizational and informational aspect, further specifications are typically used. They describe policies concerning who is involved in the process and how data may be accessed or how it may flow, for example in the form of security models, such as ACL, RBAC, Bell-La-Padula or Chinese wall. These policies will be subsumed under the overall policy.

#### **2.1.1.1 The Process Model**

As outlined in the right-hand part of Figure 2.4 a process model consists of tasks, where each task represents an activity of the process and its respective execution dependencies, that is, an activity literally is a task that is actively executed by a user. Activities themselves are conducted sequentially or in concurrent order. The execution of activities can depend on decisions such that there are branching situations that cause the process execution to follow different paths. The decision on the direction to take can base on process-related or contextual properties, such that process activities can be linked to conditions and obligations in different ways. Further, parts of a process may be conducted multiple times. A process model can also be instantiated. This means that an execution sequence of a process model consists of task executions, which enables a design-time representation of a case of the process.

A process model primarily stands for the business process and the business goal to be achieved. Security requirements of the functional and behavioral aspects mainly focus on the relationship between the activities. For example, they require that for the evaluation of a collateral. a market value computation must always be carried out and that in any case a check of this computation must only happen afterwards. Many such requirements can be covered by the explicit definition of the control flow in the form of process models. They can be checked with so-called patterns to facilitate re-use [169]. Patterns also build the bridge to other security policies, or in general safety or liveness properties, for instance expressed by means of Linear Temporal Logic (LTL). Such patterns can check if a given control flow supports a required behavior. For secure process execution, it is important to strictly comply with the requirements on the control flow layer.

The control flow requirements can be specified in various ways. Rule-based modeling follows an Event-Condition-Action-approach (ECA) to define requirements along business rules. However, business processes are usually defined with the help of graphical models such as UML [116, 117], Event-driven Process Chains (EPCs), BPMN [118] (as in Figure 2.5) or Petri nets. These process instructions explicitly define valid process activities and the order in which they must be executed. Within PAISs, such models can be used to automatically assign users to activities and monitor execution. In BPMN, the de facto standard in process modeling, tasks are represented by rectangles. Immediate events are visualized by circles, for example, that start or end the process as shown in Figure 2.5. Execution dependencies are modeled by control flow arcs and diamond-shaped nodes, which are called

gateways. The gateway semantics determines the exact process behavior. For example, they determine whether or not the incoming arcs are synchronized (AND or XOR gateway with a plus, or cross symbol respectively). Further, for outcoming arcs, they determine whether they are activated concurrently or mutually exclusive (AND or XOR gateway) [40]. For further illustration, the CEW example is simplified and only considers the subprocess of determining the market value of a collateral, namely its computation and control. This sub-process will be called the "Determine Market Value" (DMV) process depicted on the left in Figure 2.6b. A subject computes the market value (t1) and afterwards, computation has to be controlled (t2).

#### **2.1.1.2 The Enforceable Policy**

A security policy is used to specify, either directly or indirectly, which interactions are authorized in the process. The first chapter introduced the policy classes that are typically used to specify security requirements in business processes. These four policy classes are authorization, separation of duties, usage control and isolation and can be incorporated into the specification in different ways. As mentioned at the beginning of this chapter, only enforceable safety properties can cause a reference monitor to block the execution of a workflow, thus cause an obstruction. However, not every security policy is a property in the sense that was described at the beginning of this chapter. In fact, some security policies cannot be defined using the criteria that individual executions must each satisfy in isolation. If the set of executions for a security policy is not a controllable safety property, then an enforcement mechanism for execution monitoring does not exist. Therefore, the different policy types need to be examined for their enforceability in the sense of the introduced trace properties.

In general, "every property which is formalizable as a set of traces can be written as the intersection (or conjunction) of a safety and a liveness property" [148]. This means, a sequence or trace can fulfill liveness and safety properties and encode different policies. At the same time, execution monitoring mechanisms for enforceable safety properties compose in a natural way as well. In the case where several such mechanisms are used simultaneously, the policy enforced by the aggregate is the combination of the policies enforced by each mechanism in isolation. This is of interest because it enables complex policies to be decomposed into conjunctions with a separate mechanism used to enforce each of the component policies [182]. Hence, because the policy composition does not affect enforceability, it is possible to subsequently examine each of the different policy classes separately to identify the ones that are relevant for obstructability. The policy classes therefore will be elaborated in greater detail to identify to which extent they are enforceable. Moreover, examples of typical specifications are given, which often represent models well-established in practice. In combination with the policy classes, this section will examine the related process aspects in greater detail in order to comprehensibly identify relevant policies. To the best of our knowledge, this is the first systematic attempt to comprehensively analyze the enforceability of all given classes of business process security requirements in terms of trace properties.

**Authorization:** Access control regulates the authorization of individual subjects, namely users or IT-systems, within processes or also the granting of access to corresponding resources or data. It centers on the organizational process aspect. As introduced in chapter 1, authorization means enforcing access control to ensure that only authorized individuals are allowed to execute activities within a process. Because this allows to define authorized as well as unauthorized trace properties, authorization represents an enforceable safety property [182]. Authorization forms the core of access control along with authentication. The latter is usually part of the supporting IT-Infrastructure. The information system that guides the process execution usually gets the information about authorized users from the implemented access control model. For this, Access Control Lists (ACL) or also Role-based Access Control (RBAC) are used. Corresponding roles are created for different tasks or functions, which can also be structured in hierarchies and allow for the delegation of rights. Hence, PAISs can use authorization concepts to enforce user activity assignments (e.g., an SAP-System with Authorization or similar), i.e., the mapping of process tasks to stakeholders with respective permissions and enough capacity. The informational aspect complements authorizations that purely assign process participants to activities with requirements related to properties of data elements, for instance how they can be used or produced. In particular, through the consideration of data elements, such as databases, documents or variables, certain subjects can be involved in the process or excluded, for example, on the basis of a loan amount. Such data-oriented conditions are however usually encoded or annotated in the control flow specification as refinements of branching conditions. The focus, however, is on policies that are not specified in the control flow but in a separate policy, such that situations arise in which the policy enforcement monitor can block the control flow execution.

**Separation of Duties:** A further concept that embodies the organizational aspect, is the separation, or, its dual, the binding of duties to avoid conflicts of interest or reduce the risk of fraud (cf. Chapter 1). It generally states that some activities in the processes cannot (SoD) or must be (BoD) executed by the same subject or by the same role. The specification of the authorization already allows for a structural separation or binding of duties in using appropriate access control concepts. For example, separations are taken into account when designing the organizational structure of a company. Suitable role and authorization concepts are defined to ensure that processes meet the requirements of functional separation, for instance, that different departments are involved in a process. However, role hierarchies can be very complex with the result that individuals can avoid the intended separation by acting in different roles. Thus, the separation or binding of duties needs to be implemented on an individual level as well, for example with the Four-Eye Principle, which requires that always two people are involved in a process. Such policies represent constraints that act on top of authorization. Here, based on the execution of specific activities of a user, or in other words, the execution history of a process case, the user is forced (binding) or not allowed (separation) to execute other process activities. This is how the assignment of actually authorized users is further constrained. Because such an assignment can also be encoded as a trace property, allowing or denying a respective access can be enforced during execution. Hence, similarly to authorization, the separation of duties and the binding of duties encode enforceable safety properties. Regarding the specification of authorization and SoD policies, the NIST RBAC standards provide three levels of RBAC. It allows to define basic RBAC, hierarchical RBAC which also supports inheritance between role, and RBAC-Level-2, or also called "constrained" RBAC, which supports the definition of separation of duties as well. Further, using formal descriptions of security properties, model checking techniques may also be applied, such that BoD and SoD can be verified by specifying appropriate LTL formulas as patterns as well. These specifications can be used with the help of reference monitors that are able to enforce both authorization and SoD-related policies.

**Usage Control:** Usage Control is primarily associated with the functional and behavioral process aspect and expresses conditions that must hold after the access to a resource [179]. It is often used to capture regulatory compliance and especially privacy and data protection requirements. More specifically, it requires the specification of pre- and post-conditions for the execution of process activities or the access to resources or data. Conditions not only describe the maximal number of access but also temporal relationships of activities independent of specific execution paths. They may also constrain the data retention, for example, requiring to delete local copies of a data item after its access and usage. However, depending on their observability, usage control requirements are not enforceable by a reference monitor and they encode liveness properties. However, it is possible to reformulate certain usage control policies in a way that they become controllable. Such enforceable usage control policies consider the interplay of different activities and are encoded in the control flow, typically in the course of the specification of conditions and obligations. These control flow constructs can be captured as patterns as well. Usage Control, analogously to authorization, can capture the informational process aspect as well and it can consider data elements used in the process and their influence on the control flow of the process. For example, the annotation of branching conditions with data-related constraints determines the choice of subsequent paths. The consideration of given usage control policies in the control flow is also achieved by means of process rewriting, which is challenged to keep functional and behavioral aspects of the initial control-flow. By this, it is possible to enrich a process model with activities derived from usage control policies, for example policies in which the condition determines the obligation, such as "whoever uses a service has to pay for it" or "when the data is accessed, the user must be informed". Thus, usage control policies can use the same model specification language as the process model. Hence, a big part of usage control can be taken into account in the process model. Such model-based policies, however, do not lie in the regarded area of conflict between the workflow and the execution monitor. However, there is a minor portion of usage control policies that are as formalizable as enforceable safety properties, for instance, the maximum number of access to resources.

**Isolation:** Isolation policies stem from the informational process aspect. Isolation generally says that confidentiality and also integrity of information must remain during the execution of a process. Isolation policies can be subsumed to the class of information flow policies, which define the way information moves throughout a system. Any confidentiality and integrity policy embodies an information flow policy. They either preserve confidentiality of data, to prevent information from flowing to an unauthorized user to receive it, or the integrity of data, such that information may flow only to processes that are not more trustworthy than the data [33]. In this respect, authorization and SoD represent information flow policies as well and access control can be seen as a component of information flow, in which the accessed object is the information. The informational aspect constitutes a generalization of the organizational aspect. However, its focus is on information and its distribution, not on the organization of the company in the sense of connecting resources and users to processes to eventually run a business. Isolation policies, on the one hand, address potential conflicts of interest. On the other hand, isolation policies restrict the direct and indirect flow of information in a process and the PAIS:

• As a rather organizational policy, isolation can be used to avoid conflicts of interests. Here, the aim is to prevent the flow of sensitive information between competing companies or departments involved in the execution of a process. The history of activities that have already been executed is key for the decision as to whether a person is authorized to carry out certain activities. For this, the Chinese Wall security model is able to describe business policies to separate conflicting domains in a history-dependent dynamic way. It is a model of a security policy that equally refers to confidentiality and integrity. In particular, by defining so-called conflict classes, it can be avoided that business areas that are in conflict with each other interfere and conflicts of interest arise (e.g., if competing enterprises work with the same external consultant).


Regarding the enforceability of isolation policies, for instance, the Chinese Wall security model can be enforced, because it may limit the number of tasks that any single user can perform. This also applies for Bell-La-Padula, for example when users involved in two tasks have the same security clearance. Both examples represent enforceable safety properties whose violation can be checked on the trace level. However, it is important to note that not all isolation related properties can be characterized as trace properties such that they are enforceable by a monitor. Such monitors which see executions as a sequence of performed actions are not sufficient to enforce strong information flow properties. Whereas trace properties hold for sets of traces, these isolation requirements are only specifiable as properties over sets of sets of traces, so-called hyperproperties [46]. They can be used to define strong information flow policies which specify to what extent information can be learned by users of a system, or respectively, the actors that participate in a process. Hence, strong indirect information flow policies do not define sets of properties in the sense of a trace property, so they do not define safety properties. This particularity is highlighted in the works of McLean and Schneider. McLean [148] proved that non-interference information flow policies are not trace properties. Because they are no safety properties, there are no enforcement mechanisms to enforce them during execution [182]. Hence, they cannot cause an obstruction in the sense of this work.

This difference can be illustrated with a short excursion into communication theory. If one understands the obstructive situation communication-theoretically, the trace focuses on what is said, that is, which activities are actually carried out. Based only on what is said, on the given trace prefix, an enforcement monitor can decide whether it is permissible or not. In contrast, strong information flow policies do not only depend on what is said (in terms of a trace prefix) but also on what is not said. In a sense, this can be related to Watzlawiks first axiom "One cannot not communicate" [211]: What is actually said does not only relate to itself but can be seen in relation to what else could have been said, based on a given set of possible pieces of information or messages. If this is transferred to a process, it must not only be considered how a process is executed, but also what information can be inferred from what could have been executed on the basis of the model (which is what was not executed). Nevertheless, although an obstruction results from a focus on "what is said", the question "what else could have been said" may be relevant for the resolution of an obstructive situation.

The focus of this thesis is on controllable safety trace properties, whose enforcement causes an execution monitor to obstruct the process execution. Hence, in conclusion, only authorization and SoD policies in the sense of execution monitoring are fully enforceable as safety properties. Only few usage control and isolation policies are enforceable in such a way that they can be of interest in causing obstructions. Hence, with regard to the different process aspects, an obstruction primarily shows the conflict between the functional and behavioral aspect and the organizational aspect. Besides, the informational aspect is not enforceable in its essential characteristics as far as trace properties are concerned. Strong informational flow policies are therefore not considered any further. However, some of the enforceable isolation policies also relate to users, so that, similarly to the organizational aspect, the assignment of users to activities is controlled, for example, Chinese Wall and Bell-La-Padula. Analogously to the isolation policies, only a part of the usage control policies is enforceable, for example the maximal number of resources a user can access (cardinality). Equally, for usage control, the enforceable part can be related to the organizational aspect. As a further observation, policies can also be mapped into the control flow, for instance usage control policies. Thereby, they eventually also form execution sequences or traces, which can be grasped as properties. However, because they are not encodeable as an enforceable policy, they cannot cause an obstruction and are therefore neglected.

Based on these findings, the considered policy shall typically involve the authorization policy that defines which users are authorized to perform which workflow tasks. On top of that, further polices can be involved that stem from SoD, but also Usage Control or Isolation requirements, and further restrict which of the authorized subjects can perform specific tasks. These are often called "authorization constraints", which means they are constraints on top of the basic authorization but are crucial in finally determining the user-task assignment during execution. Hence, it is possible that a user, while authorized by the authorization policy to perform a particular task, is prevented (by one or more constraints) from executing this task in a specific workflow instance because particular users have performed other tasks in the workflow before. As an example of such policy, an execution of the workflow of determining the market value shall now be constrained by the authorizations illustrated as assignments from subjects to tasks in Figure 2.6a. For example, Alice can control the computation (t2) whereas Bob is not authorized to do so. Moreover, the workflow system that executes the payment workflow has the SoD constraint that t1 must be executed by a different subject than the one performing t2. SecureBPMN [36], SecBPMN [177] or further BPMN extensions [39] <sup>3</sup> are suggestions for modeling security policies, which have, however, not been consid-

<sup>3</sup> Basin et al. provide a concept [23] and tool support [39] by extending the modeling tool Oryx with a BPMN extension for authorizations to enforce abstract SoD constraints.

ered in the standard so far. For this work, a variation of these approaches is used to model authorization constraints. The affected tasks are connected with dashed lines, whose label represents the type of the individual constraints, e.g., "-=" for SoD in Figure 2.6b and "=" for BoD.

**Figure 2.6** DMV Model and policy based on the example in Burri [39]

In conclusion, all of the identified enforceable policies can have a negative impact on the process execution, because, depending on the contextual situation and the existing execution, they ultimately may prevent available users from being assigned to the execution of a task, thus causing a workflow to become obstructed. Such a scenario may not only depend on the constraints, but may also happen when authorized users are unavailable. Existing research relates this to the general notion of workflow satisfiability and workflow resilience.

#### **2.1.2 Satisfiability**

The notion of obstruction is related to the so-called satisfiability problem of workflows. The basic version of the Workflow Satisfiability Problem (WSP) assumes the existence of a process model specification, an authorization policy, and a number of authorization constraints. Given a set of users *U*, a set *T* of tasks, and a policy, which consists of an authorization list for each user *u* ∈ *U* , which determines the tasks for which *u* is authorized, and a set of constraints on *T* . Then, the WSP asks, if it is possible to find a valid plan π : *T* → *U*, which assigns a user to every task, such that the policy, namely both authorizations and constraints, is satisfied. If a valid plan exists for an instance of the WSP, then the instance is called satisfiable. The authorization list itself can be seen as a set of specific, rather simple constraints that encode the authorization policy. However, it makes sense to assume that for every task, there is some user who is authorized to perform it. Otherwise, it is trivial that the workflow is unsatisfiable. Because this builds the basis for further constraints, the authorization list, or the authorization policy, respectively, is handled separately.

Given the introduced policies of the market value computation, the workflow is in general satisfiable because Bob can execute the first task and Alice is authorized to perform the second, which is illustrated in Figure 2.7. In other words, there exists a valid plan to execute the workflow.

The practical motivation for the WSP is based on three main reasons, which are of particular interest to policy-designers as well: The first one is that it can be used in a form of static analysis before deployment to ensure that the workflow specification is useful in the sense that there is at least one possible "execution path" throughout the workflow. Secondly, the WSP can be used to synthesize plans for workflow instances, which assign the tasks to the users for each instance of the workflow so that they can be used when instantiating the specification. Thirdly, the WSP can also be used in a more dynamic way if tasks in a workflow instance are not assigned to users in advance, which is related to obstruction-free enforcement. This section will consider the satisfiability aspects at design time, such that satisfiability can be analyzed before the execution of a process. These aspects are also connected to workflow resilience, which will be considered afterwards on the basis of this section.

**Figure 2.7** A satisfiable assigment of users to tasks

#### **2.1.2.1 Initial Publications**

Workflow satisfiability and the associated problems are an active area of research. Its beginnings date back to the turn of the millennium. The work of Bertino et al. [30] from 1999 considers the completion of security-aware workflow instances. Their exponential algorithm assigns users and roles to tasks in sequential workflows by keeping an authorized user from performing a task when this implies that subsequent tasks would not have authorized users who satisfied the workflow constraints. Thereby, the algorithm generates an actual valid user task assignment rather than deciding whether a workflow is satisfiable or not. Afterwards, "unfortunately, solutions to [the satisfiability] problem have largely been overlooked in the literature" [194]. The problem was tackled from another direction by Wainer et al. [204] in 2003. Their idea is to assign priority levels to each constraint and different override levels to users. In case a workflow is not satisfiable, some constraints may usually be overriden by unauthorized users who, however, have an override level that is higher or equal to the priority level of the affected constraints. Inconsistencies within the specification of constraints were analyzed by Tan et al. [194] in 2004. Such inconsistencies can cause an unsuccessful workflow execution. They define a model for constrained workflow systems, which includes constraints such as cardinality, SoD and BoD. The authors define a workflow as a partially ordered set of tasks and explicitly specify workflow and task instances. Authorization constraints are given for pairs of tasks in terms of relations over users that must be satisfied when executed. Eventually, in 2005, Crampton was the first to establish the term "workflow satisfiability". He refined the existing ideas by looking at workflows as partial orders, defining simple SoD and BoD constraints, and developing an algorithm to determine if there is a mapping of users to tasks that meet the constraints. This represents the basic problem formulation of the WSP. In 2006, Solworth used the notion of "approvability" and allowed SoD constraints in the presence of loops if the first allocating task is always executed by the same person. For this, an approvability graph is designed to describe sequences of actions defining the termination of workflows with an RBAC policy, sequential or conditional executions. The approaches have so far all been based on the so-called ordered version of the WSP, which means they always refer to the task order check, task by task, whether there is still a valid assignment. In 2007 Wang and Li [208] were the first to not consider the order and introduced the unordered version of the WSP. In their work, they introduce an extension to the common role-based access control (RBAC [178]) to be able to define authorization constraints and capture common workflow system security requirements (e.g., SoD). They use plans to study the time complexity of the WSP and prove that the WSP is NP-complete in their access control setting and reduced the problem to Boolean satisfiability problem (SAT), which allows the use of off-the-shelf SAT-solvers. Moreover, they prove that a workflow system supporting subject-task authorization and either so-called subject-inequality (SoD) or existence-equality (BoD) constraints (or both) to be NP-hard, however, efficiently solvable if the parameter is the number of tasks of a workflow, which is usually smaller than the number of involved users. Wang and Li's FPT proof motivated many later works by Crampton et al., all then considering the unordered version of the WSP for workflows specified as partial orders. Wang and Li further were the first to use the term of resilience in this context. With these works, foremost the works of Bertino et. al., Crampton et al., and Wang and Li, the basis has been laid for the subsequently strongly growing research interest in the field.

Since 2007, research related to the WSP has branched out in different directions. In the observation of the initial publications, essential criteria already emerge, which have then been deepened in the course of further research. Besides, it can already be observed that it is a common practice in the analysis of workflow satisfiability and also resilience to abstract from parts of a workflow specification. For example, it is common practice to limit the allowed control flow constructs or supported authorization constraints and to neglect data-oriented elements. For instance, there is only one work from 2011 that actually at least considers the data flow. However, it does not model data-flow but overapproximates data-oriented gateway decisions with an internal choice operator [24]. Further, despite its strong relations and origins to access control, it is hardly spoken of a "subject" (which accesses an object). The subjects, which can represent human users but also IT-agents or systems, are often simplified to "users", which may better reflect the business process context and the direct connection to the problem of potentially missing process participants. In this thesis, both terms are used interchangeably. Today, more than 100 publications can be counted and, to date, about 10 to 15 new papers on the subject have been published every year in renowned conferences and journals. Covering every publication in detail therefore would be too exhaustive and would diffuse the focus. Therefore, the spotlight will be on the key findings and deficits that are of relevance when considering obstructability. For this, first important aspects of satisfiability, afterwards resilience and then its runtime versions (in the section on execution monitoring) will be considered.

#### **2.1.2.2 Process Structure**

The structure of the process models upon which the different instances of the WSP in the literature are based differs. As the initial publications already indicated, differentiation can mainly be made between workflows that only allow a sequential or linear execution of tasks, and partial orders that also enable concurrent executions. There are only few other approaches that allow for choice branches and looping tasks (e.g., using Hoare's process algebra CSP [24]). In the latter case, the tasks executed in a workflow vary from one instance to another, which further implies that there may be constraints that only apply for certain sequences of tasks. In this regard, the example process in Figure 2.5 requires full support of all of the mentioned structural possibilities.

#### **2.1.2.3 Order of Assignment**

Solutions to the WSP also differ in how the order of the tasks is considered when the users are assigned. As one possible solution, the unordered WSP offers a plan that assigns users to tasks in such a way that all tasks have an assigned user and all constraints are satisfied. In contrast, the ordered version offers a plan with an execution sequence, such that the assignment must respect the ordering of tasks defined by the control flow. The ordered and unordered versions of the WSP are only equivalent for workflows with tasks that can be executed in any order [61]. For the other cases, assuming either the ordered or the unordered version can make a big difference. This can be imagined by a slight modification of the DMV authorization policy in Figure 2.6a, such that Alice and Bob would now both only be authorized for the second activity, and only Alice would be authorized for the first one. In the unordered case, assigning Alice to the second task before assigning her to the first would not allow the assignment of the first task anymore due to the SoD constraint. The ordered version would, however, first consider the assignment of Alice to the first task such that for the second task, Bob would still be assignable. In literature, the consideration or non-consideration of the order is roughly in balance while there is the tendency that the more complex the policy under consideration, the less the order is taken into account.

#### **2.1.2.4 Constraint Types**

The subsequent analysis of the constraints considered in WSP research will show that the WSP considers constraints that relate to the types of enforceable and controllable policies from process security that were determined in Section 2.1.1.2. The terminology for these policies in the WSP context differs, however, from the terminology of process security polices. The latter rather stems from business or regulatory rules. For instance, the SoD constraint against fraud can be related to the requirements of an Internal Control System (cf. Chapter 1). In contrast, the terminology of the constraint types in WSP research will manifest further references, such as the connection to constraint satisfaction problems (CSP) and its complexitytheoretical considerations, as well as the entwinements to access control research, combined with the ambition to generalize findings on the instances of the WSP and the constraints considered therein.

Therefore, in the course of the different publications on the WSP, a growing number, differentiation and abstraction of constraints types—which are in fact described very differently in the individual publications albeit they often mean the very same thing—have developed. Although some initial works followed other attempts to specify constraints, for example, Bertino et al.'s constraint specification language [30] and Li and Wang's Separation of Duties Algebra [208], the following classes of authorization constraints for workflows have meanwhile crystallized [63, 181] 4.


<sup>4</sup> Although, subsequently, these different kinds of constraints are given by the help of some formal examples, they only intend to give a better understanding of the intuition behind the provided concepts. More profound formalizations will be given in the subsequent chapters.

as separation-of-duty, binding-of-duty, and cardinality or counting constraints, are user-independent [60].

#### **2.1.2.5 Complexity and Fixed-Parameter Tractability**

At the core of parameterized complexity, there is the idea of finding an aspect of the problem that makes it intractable, namely NP-hard. Then, depending on the application under consideration, a parameter k is introduced, which measures this aspect in such a way that k would be relatively small for those problem instances that arise in practice. The aim is to design efficient algorithms called fixed-parameter tractable (FPT), which run in time *<sup>O</sup>*( *<sup>f</sup>* (*k*) <sup>∗</sup> *<sup>n</sup>c*), where f is an arbitrary computable function in k only, n the size of the problem, and c an absolute constant [71]. Being polynomial for any fixed value of k, such algorithms are extensions of polynomial algorithms for NP-hard problems. A given formula of a satisfiability problem is parameterized by the number of variables, such that the problem size *n* with *k* variables can be checked by brute force in time *O*(2*kn*). In this respect, to make the WSP fixed-parameter-tractable, Wang and Li [206] introduce the number of tasks |T| as the parameter k, arguing that in practice it is often much smaller than the number of users |U|.

At the beginning of the WSP research, it was well-known that the WSP is NPcomplete. Wang and Li [206] prove that the WSP is also W[1]-hard, which first of all means that it is highly unlikely that there is an FPT algorithm for the problem. However, in their work from 2007, they also show that WSP is FPT if the constraint set is limited to certain simple constraints. In fact, this assumption appears very natural in practice. Crampton et al. [65] extend the classes of workflow specifications from Wang and Li [207] for which the satisfiability problem is known to be FPT. Those classes include counting constraints, entailment constraints and constraints based on equivalence classes. In this way, organizational hierarchies or constraints, which for instance implement the Bell-LaPadula security model or other business rules, can be defined. The authors establish the circumstances under which an instance of the WSP has a polynomial kernel, they are able to solve the original problem more quickly by applying kernelization and show that it remains FPT for counting and equivalence constraints [64]. Crampton et al. [61] pick up the concept of constraint expressions [128] (logical combinations of constraints) to translate an instance of WSP for entailment constraints with unrestricted cardinality into multiple instances for singleton entailment constraints. The underlying idea is that an instance of the WSP for a conditional workflow can be solved as many instances of parallel workflows. By this, it is uniformly possible to support conditional workflows and entailment constraints with no limit in cardinality and thereby keeping fixed-parameter-tractability. They further develop a first solution [59] to the WSP regarding seniority constraints and specify special cases that are fixed-parametertractable in which they are still able to represent common subject hierarchies from practice. Cohen et al. [49] solve the WSP using techniques for the Constraint Satisfaction Problem, which allow the authors to present a generic algorithm to solve the WSP using the general constraint types: cardinality, so-called regular (e.g., SoD) and user-independent constraints. Their solution builds executions incrementally, discarding partial executions that can never satisfy the constraints. The authors show that their algorithm is optimal for user-independent constraints. As an important landmark, Cohen et al. further introduce the aforementioned notion of userindependent constraints [49], which constitute a natural generalization of the simple constraints Wang and Li considered. Crampton et al. [60] were the ones that did extend the notion of user-independent constraints to that of class-independent constraints. They show that such WSP remains FPT and propose an algorithm to solve it. It is shown that user-independent constraints provide a good trade-off between expressive power and tractability. On the one hand, user-independent constraints include many workflow constraints of practical interest. On the other hand, the WSP remains FTP if user-independent constraints are considered. This focus on userindependent constraints enabled the development of highly efficient algorithms and tool-support [47, 63, 125]. For example, Crampton et al. [60] and Cohen et al. [47] show the superiority of their FPT algorithm in comparison with the classical SAT reduction of the problem.

#### **2.1.3 Resilience**

Resilience asks to what extent a workflow is satisfiable against the absence of users, for example due to vacation or illness. Thus, it is a question in the context of the WSP, which represents a way of conditioning the WSP on the basis of constraints that are independent of the workflow. As a preliminary study, Li et al. [135] introduce the concept of resilience policies for access control systems. These policies specify a minimum number of users who must have certain privileges. Thereby, an appropriate level of redundancy is ensured in the system so that the system is resilient to the absence of users. The resilience checking problem (RCP) related to this, draws on the ability to check whether an access control state satisfies a particular resilience policy. Wang and Li [206] then examine resilience in the workflow system context and its relationship to theWSP. Based on the observation that there are different types of workflows whose execution time frame varies between hours, days and weeks, Wang and Li propose a three-layered view on resilience in workflow systems [207]: (1) static resilience—some subjects are absent before the execution while remaining subjects will not become absent during the execution; (2) decremental resilience subjects are absent before or during the execution and absent subjects will not become available again; (3) dynamic resilience—subjects may be absent before or during the execution and absent subjects may become available again. A workflow is said to be (statically) k-resilient and remains satisfiable even after any k users are removed from the current state.

Regarding the market value example, suppose that Alice becomes ill and is not available to participate in the execution of the workflow: Although, based on the authorization policy, Bob is authorized to execute all tasks of the workflow, he will not be allowed to perform *t*<sup>2</sup> after executing *t*<sup>1</sup> due to the SoD constraint. Similar problems would arise if Bob was not available. Hence, the absence of either Alice or Bob would result in an unsatisfiable workflow, which is why the example workflow specification represented in Figure 2.6 is not resilient for *k* > 0 absent users.

Solving resilience questions can clearly be motivated by similar aspects for policy designers as done for the WSP. Moreover, it is of particular interest for emergency planning, which is important for many companies today. As identified in Chapter 1, a policy should follow the principle of least privilege such that access is only granted if it is absolutely necessary. Resilience requirements have a completely contrary conception. For example, the mentioned resilience policies show the attempt to capture these opposing goals by means of a policy as well. Looking for ways to reason on and resolve the contradictions between conventional access control policies and resilience requirements is an active research area, and a challenging task for policy designers.

In essence, resilience is associated with ensuring the achievement of business goals even if some users are not available for the tasks that contribute to the achievement of those goals. Although this has similarities to the general aim of this thesis to ensure the achievement of business goals, an obstruction does not necessarily happen due to an unplanned absence of users, but is rather caused by the policy. Nevertheless, based on these similarities, resilience approaches offer interesting concepts, so that the following aspects will also be of interest for considerations to detect and handle obstructions.

#### **2.1.3.1 Synthesizing Execution Plans**

The generation of execution plans is an important component in determining resilience because the existence of multiple valid plans makes it possible for a workflow to be completed even if a number of users are absent. Literature about the synthetization and verification of such plans for security aware workflows addresses different levels of resilience. Crampton et al. [57, 66] use bounded model checking to generate authorized plans and derives measures to evaluate the resilience of solutions by obtaining the sizes of minimal subjects bases [68]. Thus, before the execution of a workflow, it can be analyzed what the minimal subject base is to complete a given workflow during execution (static resilience). As Lowalekar et al. [138] point out, several assignments with the same degree of k-resilience may exist such that it may be necessary to pick the most favorable one. As an approach related to decremental resilience, Paci et al. [158] generate a set of valid plans that are stored to decide which user to assign to a task in case the previously assigned user is unavailable at runtime. For this, they introduce resilience constraints that state the minimum number of users for a satisfiable execution. They describe a process to be user-failure-resilient if a user-task assignment that meets the resilience as well as the security constraints can be found. Massaci et al. [145] propose an approach to analyze also a priori execution if a given subject assignment is resilient against the dynamical absence of subjects.

#### **2.1.3.2 Quantification**

Instead of investigating the maximum number of absent users (k-resilience) or the minimum number of available users (minimal subject base), the so-called quantitative resilience, proposed by Mace et al. [141], examines the probability of the availability of the users. Based on this, the path that offers the highest degree of resilience with regards to the maximum probability of a valid process completion is determined. Therefore, quantitative resilience seeks to measure the extent to which a workflow is resilient, rather than simply deciding whether it is resilient or not. Thus, with the introduction of quantitative resilience, the risk of user absence, or its cost respectively, is quantified for the first time.

#### **2.1.3.3 Feasibility and Change of Policies**

As for the risk, one is willing to take, to achieve resilience, literature is going further. Thus, it can be considered which policy changes are needed in order to make a nonsatisfiable process specification satisfiable. These changes can be connected to risks or quantified as costs. The idea to edit the policy was initially associated with the concept of feasibility [128]. The authors describe workflow feasibility as the dual of workflow resilience. Hence, their intention is to not "boil down" a given workflow specification to a critical state to assess its resilience, thereby determining the minimal subject base or maximal number of absent users. In contrast, they consider a workflow that is not satisfiable, such that the question is, if it is feasible at all to somehow complete the workflow. They use relationship-based access control, which allows them to repair the policy by edge addition or removal in a social network. With regards to the constraints needed to address the workflow satisfiability problem, relationship-based access control models, however, only offer a limited way of specifying authorization policies. Nevertheless, feasibility represents the basic idea in repairing and changing the policy to allow for satisfiability, which is then explored in further works. For example, the idea to change the policy is used by Basin et al. [25] which use a cost-based approach to increase the resilience of a workflow. Given an unsatisfiable workflow, a new user-role assignment is determined, whereby the costs of change regarding the risk of a role substitution, maintenance and administration are minimized. Further, Mace et al. [142] allow policy designers to automatically evaluate workflow resilience and compute optimal security constraint changes to ensure a certain resilience threshold.

#### **2.1.3.4 Policy Violation**

A further, in a sense more drastic, step towards reaching resilience of an unsatisfiable workflow is the violation of the policy. Here, the risks associated with a policy violation are considered. With the so-called Valued WSP [62] and its refinement, the Bi-Objective WSP [63], Crampton et al. define approaches to optimize the user-task assignment for a workflow that is unsatisfiable, for instance due to user unavailability, such that the "least risky" assignment is found in order to achieve resilience. They distinguish between the authorization constraints and the authorization policy, which can be violated in order to complete a workflow. The risk associated with the violation is expressed as a cost. The algorithms that find a usertask assignment which completes the workflow with minimum cost, is shown to be fixed-parameter tractable with user-independent constraints. The bi-objective WSP aims to minimize two weight functions associated to a valid plan, one representing the violation of constraints and one representing the violation of the authorization policy, which results in a set of incomparable solutions (a Pareto front), allowing the user to choose the most suitable. This may help policy designers to find a plan that, for example, ensures that the cost of constraint violations is zero and that the cost of policy violations is minimized. If the overall cost is zero, the workflow is definitely satisfiable. In relation to Mace et al. [128], Crampton et al. [63] further show how their approach can be used to consider user availability as well. On the one hand, there are the costs of assigning an unauthorized or unavailable user. On the other hand, there are the costs of assigning an authorized user, which correspond to the probability that the user is not available. The work by Crampton et al. also touches on works related to risk-aware access control [43, 44, 80, 156], which aims to quantify the risk of letting a user execute an action instead of just making a decision to approve or deny such action. It also ensures that the accumulated risk remains within certain thresholds. However, unlike other work, their focus is on calculating user-task assignments at minimal cost instead of access control decisions [62].

It can be concluded that, if a workflow is found to be unsatisfiable, it can never be completed without changing or violating the security policy. The areas of costs, policy changes and violations, and user availability can also be considered together. For example, the approach of Crampton et al. on the one hand allows a consideration of whether the risk of a violation is greater than the risk that the actually authorized user is not available [63]. All these metrics and costs ultimately represent indicators, which, as shown above, can be used to minimize violations, to not exceed thresholds, or to indicate options for action, among which the user has to choose.

#### **2.1.4 Obstructability: The New Factor**

As a general observation, checking for resilience of a satisfiable workflow is comparable to putting a healthy patient through his paces at the doctor's in order to compare his vital values with the critical threshold values that indicate illness. In contrast, the feasibility, or more generally the change or violation of the policy, assumes a sick patient, who should become healthy again with targeted measures, or in other words, it checks whether the restoration of health is feasible at all. These two poles of approaching resilience and related problems are reflected in the identified different aspects of existing research.

The same metaphor can be used to illustrate the difference between obstructability and obstruction. Checking obstructability assumes an actually "healthy" process specification, comparable to checking satisfiability or resilience. In contrast, the assumption that an obstruction is given, can be compared to the case of having a sick patient, so to say, a "sick process instance", which must be treated in such a way that it can recover, i.e., that the process can be completed. Because the latter happens during the execution time of the process, it will be covered separately in the next section. For the preventive analysis, in analogy to satisfiability and resilience, the notion of obstructability of a security-aware workflow is introduced. Given a security-aware workflow, obstructability asks: Is there a partial assignment of users to tasks of the workflow (or a partial plan) that obstructs the execution of the complete workflow, such that no other authorized user can be assigned to the remaining tasks? In terms of its effects, obstructability, as opposed to satisfiability or resilience, describes a danger rather than a desirable ability. Nevertheless, it appears reasonable to examine security-aware workflows from this point of view as it allows to reveal whether and to what extent obstructions are present therein. The mere analysis of the satisfiability or resilience tends to neglect or overlook the cases of possibly still existing obstructions, which will be examined in the following.

Regarding satisfiability, if a workflow is unsatisfiable (and not trivially unsatisfiable), this definitely means that there are only permutations of user-task assignments possible that are not able to fully execute the workflow, which in an ordered assignment represent obstructions. However, a satisfiable workflow may still be obstructable. Given the DMV example in Figure 2.6, for which satisfiability and 0 resilience was attested, and that all users are available, if Alice executes the first task, the execution of the second task will be obstructed by the policy. This obstruction is depicted in Figure 2.8. One the one hand, this is because Bob is not authorized to execute the second task. On the other hand, Alice would in fact be authorized to do so based on the authorization policy. However, due to her execution of the first task, it would conflict with the SoD constraint. This means, the satisfiable DMV workflow contains an obstruction. It is this simple example that clarifies that satisfiability does not mean obstructability, and that obstructability is not the same as non-satisfiability. Obstructability, however, looks at satisfiability from the opposite angle: Every unsatisfiable workflow is obstructable, but obstructable workflows are often satisfiable. In this way, an obstruction-free process specification is not the same as a satisfiable one either.

**Figure 2.8** An obstructed execution after Alice is assigned to the first task

Regarding resilience, a resilient workflow is equally not necessarily obstructionfree. Suppose that, in the example, there was Claire and Dave as the third and the fourth user. Claire has the same access rights as Bob, Dave has the same rights as Alice. Now, if either of the four was absent, the workflow would still be satisfiable, such that it would be 1-resilient. However, if either Alice or Dave was absent, the aforementioned obstruction, as given in the example above, would still occur, if one of them executed the first task. Hence, resilient executions can still obstruct. However, obstructability can be compared to resilience to a certain extent because it is the organizational aspect that blocks further execution as well. The relationship between obstructability and resilience can therefore be stated this way: The foremost reason for obstruction is a policy problem because it is the policy that blocks further process execution. This policy problem can however, be amplified from a lack in resource availability.

In conclusion, it can be observed that satisfiability and resilience only indicate the fact that there is the possibility of the workflow being able to be completed, potentially despite absent users. They concern the whole process specification, that is the workflow and its policy. In contrast, obstructability means that the process specification inherits the danger to obstruct but can in general be satisfiable or resilient. As introduced at the beginning of this chapter, an obstruction happens in a single case, which resulted in the chosen sequence, case and trace perspective to describe security properties . Hence, the difference in these concepts lies in the model vs. the case-based perspective, which clarifies why a satisfiable or resilient workflow may still contain obstructions.

Obstructability analysis before execution can clearly not handle an occurring obstruction. However, it is able to identify weak spots of the policy and build the basis for considering how to improve the policy or to handle such situations at runtime. Similarly to satisfiability research in its first years, it seems that obstructability has been overlooked as well, although capturing and handling obstructability is gradually becoming more relevant in research and industry, as Chapter 1 has shown. To the best of knowledge, this is the first work to explicitly introduce the "obstructability" of security-aware workflows as a notion.

#### **2.1.4.1 Requirements for Obstructability Analysis (ROA)**

For the analysis of obstructability, executions that represent a blockage between the policy and the workflow must be found. Analogously to satisfiability, the trivial case of such an obstruction would be that the policy simply does not provide authorizations for every task of the workflow. Only considering that this trivial case is not given, allows to speak of an obstruction in the sense of blocking actually authorized users, which, however, are not authorized in the obstructive situation. Hence, the interesting elements of the policy that actually cause an obstruction, are the constraints put on the basic authorization policy whose access control decisions depend on the execution history of the workflow instance. As shown before, obstructability contains elements of both satisfiability and resilience. Therefore, the findings and deficits of the different aspects of existing works on the preventive analysis of resilience and satisfiability are illustrated in order to formulate requirements that enable an adequate analysis of obstructability as well.

**Ordered Assignment and Pre-Assignments (ROA-1):** Constraint satisfaction in related work is often assumed to be independent of the ordering of tasks because the policy is defined in terms of sets and functions, and plans are also defined as functions. In fact, the ordering of tasks is only relevant to the sequence in which the tasks of a workflow instance are executed, not in determining whether there is a valid plan, which is the basic application of WSP and resilience approaches. From the perspective of obstructability, however, it is exactly this sequence that encodes the execution history that is of interest. For example, the obstruction described in Figure 2.8, has no connection to reality if first the controlling of the computation is performed by a user before it is clear who actually does compute the market value. Hence, because obstructions consider the individual process case, it is natural that the assignment of users to tasks must take the ordering of tasks into account, which is defined by the control flow. Because an obstruction can only occur with respect to this task execution order, the ordering of tasks is actually implicitly assumed. However, based on this, a further distinction can be introduced, namely between the actual task execution, and the bare assignments of users, which will be termed as pre-assignments. In fact, situations may arise, in which a specific task at hand cannot be executed because succeeding "later" tasks have already been pre-assigned to users, tasks that should not have been executed yet. It may be the case that such pre-assignments must be preserved, and may not be canceled, for example, because it must be ensured that a task is only performed by a specially qualified user. Indeed, it is not untypical in the conduct of a PAIS to first reserve users for specific tasks before they are actually ready to be executed, for example to ensure that the process execution runs through without user bottlenecks. Based on this observation, a differentiation between the ordered version and the unordered version of an obstruction is introduced. While the ordered version of an obstruction assumes the tasks to be assigned and executed at the same time, the unordered version differentiates between these time points, such that it may be the case that tasks that are to be executed later, have already been assigned to users. This can be compared to the computation of a plan, which is used to prepare its actual execution. Such an "unordered" version of an obstruction means, an obstructive situation may be caused by such pre-assignments as well (or at least takes pre-assignments into account). It, however, still relates to the task execution order. More specifically, it encompasses an "unordered" (in the sense of not sequential) pre-assignment of users to tasks, and an ordered assignment with respect to the users that actually execute the tasks.

**Comprehensive Structure (ROA-2):** As indicated in the CEW example, the structure of a business process or workflow does not only need to be sequential or concurrent. Currently, more comprehensive models hardly exist in WSP literature at all. Few approaches consider control-flows that are more complex than partial orders. However, because they do not focus on obstructability, they rather implicitly also analyze obstructions but do not explicitly find them, nor are they able to adequately capture and represent them. Because this dissertation aims for a practical solution, it also tries to capture the most realistic and comprehensive workflow representation for the definition of the problem of obstruction. This means sequential, concurrent, parallel, conflicting and looping activities shall be allowed. In this way, it is also possible to further consider our example, which represents a process template from practice as well.

**Allow for Efficient Techniques (ROA-3):** Literature discussing WSP and resilience in workflows mainly offers theoretical approaches that focus on understanding the complexity and finding efficient solutions to the problem. In particular, research related to the WSP shows that (under the assumption that P-=NP) the NPcomplete WSP is efficiently solvable for a growing number of constraint types. The relatively efficient algorithms developed for this purpose assume that the number of tasks is significantly smaller than the number of users who are authorized to perform tasks in the workflow, as well as that all constraints are user-independent. The efforts to stay in the class of FPT problems to solve the problems efficiently should also be considered for the analysis of obstructability. Hence, the envisaged representation to reason on obstructions should allow for an efficient light computation as well. This also means that preferably only constraints that support this goal should be used.

**Common Constraints (ROA-4):** Because of the aim of this work is to consider obstructions which result from a conflict of the enforcement of security properties and the workflow, the enforceable policies, namely the authorization and further constraints, are considered. Although there are different representations of how authorizations are encoded (e.g., RBAC), they ultimately encode the possible assignments of users to tasks. Therefore, the basic authorization, that is, the basic user-task assignment as it would be represented in an ACL, is sufficient to consider. Against the identified manifold facets of constraints "on top" of the authorization policy, it is not surprising that rules, such as SoD or BoD, which initially appear intuitively plausible, seem rather complicated in the course of the development of the constraint terminologies in WSP research. Here, SoD and BoD constraints will be considered because they are typical user-independent entailment constraints in related work and in practice. Due to the practically oriented focus of this work, the terms "SoD" and "BoD" will continue to be used. However, thereby, the existence of further constraints and constraint classifications needs to be taken into account such that it is possible to integrate respective extensions.

**Synthesizing Partial Plans (ROA-5):** The approaches to synthesize execution plans seem promising to be adapted to synthesize partial plans, which are needed to indicate obstructive sequences. For instance, the number of such obstructed executions may allow policy designer to asses the given extent of obstructability, when they are related to the number of satisfiable ones. The synthesizing of partial plans may also inspire solutions to find the partial plan to complete an obstructed state (in the sense of liveness).

**Considering Costs (ROA-6):** To address the identified need to take indicators into account (cf. Chapter 1), obstructability analysis should allow to consider costs. A key question in analyzing and especially handling obstructions is, what needs to be changed or which parts of the policy need to be violated in order to allow for process completion. The investigation on satisfiability and resilience revealed comparable questions, in which an unsatisfiable workflow is assumed, whose policy needs to be changed or violated in order to reach satisfiability or resilience. Because the basic idea of this thesis is to also take a certain degree of violation into account, while still being policy-compliant to allow for more (compliant) behavior, especially the assessment of the violation with a cost is adjustable for obstructability analysis. In literature, the possibility to assign costs to violations is rather coarsegrained, for instance, it is not possible to weigh individual user-task assignments with different costs. More fine-grained approaches would allow for more securitysensitivity, which could be realized by not differentiating between constraints and policy violation, but rather allowing to asses each violation separately. Clearly, this also stresses the aforementioned requirement to consider the order because violation can be history-dependent and order-dependent as well. What the literature on satisfiability and resilience has in common with the handling of obstructability is that it does not consider changing the order of tasks, namely the control flow, because this would change the business goals encoded therein.

**Capture the State of Obstruction (ROA-7):** For an adequate analysis of obstructability, not only the requirements to perform an comprehensive analysis, but also how the analysis results can be captured and presented, should be taken into account. What all approaches on satisfiability and resilience have in common is that they only sparsely allow to actually specify an obstruction in relation to the information provided from the process specification. Basin et al., for instance, basically regard an unsatisfiable sequence as a partial execution sequence. As a more promising, yet still deficient example, the Bi-Objective WSP models such a partially completed workflow instance by adjusting the policy such that the set of authorized users for each previously executed task is reduced to the user who executed the task. This is clearly problematic when loops are supposed to be supported as a structural element because a recurring activity could then only be performed by the ever-same person. Further, the fact that an obstruction foremost represents a conflict between the organization and the functional and behavioral aspect, is what also manifests the usual and often reasonable practice of separating the process specification into its different aspects. Hence, related work does not allow to get a big picture to comprehensively represent the overall state of the system regarding an obstructed process. Therefore, obstructability analysis should be able to depict its analysis result, namely identified obstructions, in a comprehensive representation. For this, not only workflows and the policy need to be specified, but also the obstructed state, such that the execution (and (pre-)assignment) history can be encoded, and all existing information is provided. Thereby, it should be allowed to capture the overall PAIS system state regarding the considered workflow and its policies in one comprehensive representation. Because an obstruction identifies a possible weak spot of a policy and its workflow, such a representation can also help the policy designer to better visualize and comprehend, and finally improve the policies.

In conclusion, an approach for the analysis of obstructability is supposed to consider the order in the explained sense, a comprehensive process structure and costs, allow for efficient computation, and to capture and visualize the overall state of obstruction. A representation that meets with these requirements could then also be extendable to investigate and capture satisfiability or resilience as well.

#### **2.2 Process Execution Monitoring: The Case of Obstruction at Runtime**

The general notion of execution monitoring "includes security kernels, reference monitors, firewalls, and most other operating system and hardware-based enforcement mechanisms that have appeared in the literature. The targets may be objects, modules, processes, subsystems, or entire systems; the execution steps monitored may range from fine-grained actions (such as memory accesses) to higher-level operations (such as method calls) to operations that change the security-configuration and thus restrict subsequent execution" [182]. This thesis considers execution monitors in the sense of reference monitors that are implemented in a PAIS, allowing or denying access from users to the process tasks (as depicted in the AAA-Figure 1.6 in Chapter 1). Such execution monitoring enforces security requirements during process enactment (cf. BPM lifecycle) and encompasses passive observation and active interception [33] (which relates to the only-observable and the controllable security properties [26]). On the one hand, preventive monitors actively control the access of users to tasks during execution, thereby enforcing safety properties. In contrast, detective monitors observe the execution and can detect a violating behavior and possibly trigger some sort of mitigation action. The latter, which considers safety properties as well, but may also be able to assess liveness, will be considered in the section on detective analysis (Section 2.3). The core assumption in execution monitoring (in the preventive sense) is that if something unwanted happens, it shall be stopped. While this may be true in a classic access control context, based on the observations in Chapter 1 on the conflicting interests between security and business goals, this may not be desirable on the business layer with respect to business processes in a PAIS. The question of obstructability of security-aware workflows becomes a real danger if a PAIS actually blocks at runtime. It represents the decisive phase to identify, avoid or handle obstructions. Hence, during execution, it is not about the analysis of obstructability but the question is rather how to deal with actually occurring obstructions at runtime.

This chapter discusses which existing approaches there are to actually handle runtime obstructions or related problems. After a closer look at the different process elements and notions during runtime, it will be investigated how PAISs actually enforce the execution. Afterwards, the ways how preventive monitors are able to handle obstructions will be considered in more detail. Thereby, analogously to the previous section on preventive analysis, deficits will be identified such that requirements can be deduced how to allow for a more adequate handling of obstructions. Because an obstruction at runtime results from the process specification, this section strongly builds upon the findings on preventive analysis in the previous section. The selected literature in this section is therefore examined with the focus on the avoidance and handling of obstructions. It does not go again into details on the different aspects found in section 2.1 and the already deduced requirements, for example regarding structural process components or computational complexity.

#### **2.2.1 Process Enactment**

The focus of this subchapter is on the execution phase of the process and related entities, such that also the PAIS, which in fact steers the process execution, will be regarded in more detail. Examining the information system in which an obstruction of the process execution happens at runtime, then allows to better relate existing approaches to the overall setting given by a PAIS.

#### **2.2.1.1 Process Execution**

The central part of Figure 2.4 depicts the terminology in the phase of enactment (as related in Table 2.1), that is, the point of time of the actual execution of the process. A process is enacted by instantiating activities and executing them in a coordinated manner. This coordination of the activity executions takes place within a certain scope, which is called *case*. A case represents an instance of the process. It encompasses all activity executions that refer to a particular trigger, such as a so-called start event (in BPMN), or a particular input to the system for which the behavior is described by the process [40].

#### **2.2.1.2 PAIS Steering Execution**

Based on the configuration phase of the BPM lifecycle, different types of information systems can come into use, which then support the execution of a process. An important criterion here is whether the system is process-aware. Even if this is not the case and the execution of a process is completely manual, information that is created or consumed during the execution of the process (e.g., valuation of collateral and corresponding values) is often stored in a database or a document management system. If one remembers the Anglo-investigation from Chapter 1, for example the email material that revealed some of the fraudulent behavior, there was probably a database system, an e-mail program, a spreadsheet program, or a text editor. Even when such systems do not support an automation or a coordination of activities, the execution of a process can manifest itself in such information systems either way. For instance, the Anglo-emails may reflect the triggering of certain business activities. In this sense, such systems or tools may be used to execute tasks in some business process. However, these tools are not "aware" of the processes they are used in. Therefore, they cannot be actively involved in the management and orchestration of the processes they are used for [3].

Apart from this indirect support of a process, the already introduced PAIS represents a specialized type of information system to support process automation. There are many manifestations of such systems, for instance BPMS (Business Process Management Systems), WFMS (Workflow Management Systems), ERP (Enterprise Resource Planning) systems, CRM (Customer Relationship Management) systems, rule-based systems, call center software or high-end middleware, such as Web-Sphere. These systems all have in common that there is a process notion present, that they are aware of the processes they support, and that they can be configured in some way (through an explicit process specification, via predefined settings, or using customization) [3]. As briefly explained in Chapter 1, a specific class of PAISs is formed by generic systems that are driven by explicit process models. Examples are BPMS and WFMS. WFMS primarily focus on the automation of business processes [119]. A WfMS directly implements behavioral and functional aspects defined by the model, creating cases according to the provided blueprint. The basic problems of satisfiability and resilience assume such systems as well, which in practice usually provide basic authorization enforcement, whereas support for authorization constraints in such systems is rare. BPMS has a broader scope: from process automation and process analysis to process management and the organization of work [81]. What BPMS and WFMS have in common is that they both support the coordination of activity executions based on the process specification and allow for process automation.

This thesis assumes a PAIS in the sense of a BPMS because it provides holistic support for the specification, execution, monitoring and auditing of intra- as well as cross-organizational workflows, which also entails the consideration of the different process phases of the BPM lifecycle. The use of such a PAIS does not necessarily mean that all activities are automated. They can still be performed manually. However, the PAIS supports the coordination of the execution. On the one hand, activities to be executed can be selected and assigned to possible users based on the policy. However, outstanding activities can also be made available to users for selection. Thereby, and as a contrast to traditional WfMS, the users are commonly in control of which activity to execute. As a consequence, they may also allow the users to deviate from the process specification given by the underlying process model, thereby providing a degree of flexibility, which is crucial in many application domains to keep a certain room for maneuver [40]. This could, for example, mean that in the collateral evaluation process, depicted in Figure 2.5, an employee could deny or accept the acquisition before the respective collateral market value has been controlled. Although this would not be in line with the process as defined in its model, such a deviation can make sense based on contextual factors that are not captured in the process model. However, in the Anglo case, it would indicate suspicious behavior because the control activity was skipped. Such flexibility, however, does not exclude the case of obstructions because, despite all flexibility, process tasks in the normal case still need to be executed to reach the business goal of the process. Hence, processes have to be completed and the provided flexibility needs to support this. Such process-aware information systems with suitable steering mechanisms can be used, for example, to conduct certain paths defined in the specification and thus meet requirements with regard to the control flow, that is, the interplay of different activities in the process. Hence, a PAIS is able to enforce a plan (a user task assignment), such that, in case it obstructs, it can also enforce a plan to resolve the obstruction.

#### **2.2.2 Avoiding Obstructions**

If an obstructable process specification is enacted with such a PAIS, there is the danger of an obstruction factually occurring at runtime. To address this, literature, on the one hand, does not focus on the obstruction but how to avoid it. This has resulted in the development of avoidance strategies, namely preventive monitors that avoid an execution to become obstructed by enforcing only execution plans that are obstruction-free. In particular, this has a strong relation to the synthesization of execution plans as elaborated in Section 2.1 because these plans can be seen as a guide to enforce an assignment of users to tasks that allow for a satisfiable or a likely satisfiable (in case of quantitative resilience) execution. Put differently, obstruction-free enforcement aims to suppress the potential obstructability of a process specification.

#### **2.2.2.1 Enforcing Obstruction-Free Workflows**

In analogy to Schneider's enforcement classes, Bertino et al. [30] provide a categorization of authorization constraints in workflow systems into static constraints (enforced at design time), dynamic constraints (enforced at runtime), and hybrid constraints (enforced at design and runtime) [134], which is also useful for obstructionfree policy enforcement. Although obstruction-free policy enforcement may also be enforced by static constraints, the subsequently observed literature is mostly concerned with obstruction-free enforcement during runtime. Basin et al. [24] introduce an algorithm realizing this goal. Thereby, they provide a mechanism to enforce only processes that are obstruction-free (based on a trace-based notation). Crampton et al. [67] present two mechanisms to analyze the realizability of a workflow instance under given access control constraints, which can support authorization enforcement before the execution (static) or during the execution (dynamic) of a workflow. Bertolissi et al. [31] and dos Santos et al.[52], similarly to Basin et al. [24], provide approaches for the automated synthesis of run-time monitors to enforce authorization policies in business processes. In particular, they develop enforcement mechanisms that try to prevent the reaching of an obstructed state. As elaborated before, the field of obstruction-free enforcement has strong interrelations with the aspect of synthesizing execution plans. In essence, it means that the plans that were computed before process execution find their application to enact the process during execution. Therefore, the regarded literature can also be seen as an extension to the approaches presented in Section 2.1.

#### **2.2.3 Handling Obstructions**

Even if the satisfiability of a workflow has been analyzed before, if the minimal number of subjects for a resilient execution is known or if the workflow is analyzed to be obstruction-free, and even if, based on all these findings, preventive monitors aim for an obstruction-free execution, exceptional situations, in which the execution of a workflow becomes obstructed anyways, can still suddenly occur . It is not enough to try to avoid obstruction but they need to be handled. Therefore, another direction in literature lies in actually handling obstructions that occur during runtime. In Section 2.1, the analysis of literature already identified approaches that seem useful to actually complete obstructed process executions at runtime as well. For example, the approaches of changing or violating the policy in the preventive analysis can serve as a basis for finding partial execution plans that take a certain degree of risk into account and that can complete runtime obstructions. Such a handling of obstruction has its similarity to the aforementioned obstruction-free monitoring, because it provides execution plans too. These approaches however, require, for example, the change of policies or imply violation, which means that obstructionfreedom has a certain cost, a certain "price to pay" or risk. Further, while obstructionfree enforcement mechanisms focus on valid plans, handling obstructions focus on the executed obstructive partial plan. In order to complete the workflow execution, its aim is to eventually find and append a partial plan to the obstructive partial plan. Beyond that, there are further approaches to handle obstructive situations that originate from the area of access control. There are mainly two approaches to access a certain object for the case when no subject is available [70]: the concept of "Break-Glass", which often relates to the clinical context in case of emergency, and delegation. Thus, a look at these concepts is first taken, in order to set these in relation to business processes and the associated approaches.

#### **2.2.3.1 "Breaking" the Policy**

In a Break-Glass scenario, if the execution blocks an attempted access to an object, it explicitly asks whether it should be resumed. For example, the user that is blocked by the execution monitor must confirm that she or he has exceptional privileges and can be held responsible for access misuse. It is the user, who must balance potential use against harm. If the user "breaks the glass", the policy violations are recorded along with the further process execution such that after the execution, a so-called post-access evaluation can take place, and traceability and accountability are given. The costs of Break Glass are therefore strongly influenced by (manual) audit costs, which is why there are automation approaches as well [37, 163]. However, this does not significantly address the problem that Break Glass approaches override initial constraints, disregarding their security related intention or responsibilities of subjects to certain tasks. In a way, Break-Glass defines alternative constraints that take action in the case of an obstruction. The assessment of the cost of overwriting is exclusively dependent on the user who is in full control over the access. The system is not in charge, which involves the risk of user abuse.

Regarding business processes, overriding security constraints to enable a workflow to complete was considered in other works that appear in the literature as well. The approach of Wainer et al. [204], introduced in the context of the WSP, allows to override policies in exceptional situations as well. This is, however, only possible if the overriding users possess the necessary predefined override level, and the affected task does not surpass this, which allows to contain the possible transgressions to a certain extent. Brunel et al. [38] directly incorporate the possibility of violations into the policy. Their approach introduces a violation management, such that a security constraint is allowed to be overridden. However, its overriding implies pre- or post-conditions that need to be fulfilled such that the security policy is eventually met. In a sense, it represents a combination of Wainer's pre-assigned override levels (as a pre-condition) and break-glass post-access evaluation (as a post-condition).

#### **2.2.3.2 Delegation**

The other concept of access control to handle missing users is delegation, such that another subject is empowered to access the object (cf. the delegation required by the BaFin in Chapter 1). With regards to the override of initial constraints disregarding their security-related intention or responsibilities of subjects to certain tasks, delegation seems less harmful because the initial constraints of a workflow are mostly retained, except for the right that is delegated to another subject to be able to execute a task. Nevertheless, delegation involves the danger of collusion of subjects and misuse [209] (as seen for example in the Anglo-case). It further requires the delegator to be available to perform the delegation. This raises the question what happens if a user who is able to delegate her or his right unexpectedly becomes unavailable herself or himself so that she or he is unable to delegate her or his right regarding a critical task. The approach of Crampton et al. [70] considers these deficits and suggests the concept of auto-delegation, in which qualifications that indicate a potential delegatee are introduced. Examples on how the so-called qualification hierarchy may be computed based on an RBAC-model are given. In this way, a mechanism automatically resolves user unavailability by delegating a task to the most qualified available user. Because this work is located in the context of access control, the satisfiability and completion of processes is not taken into account. However, the basic idea of Auto-Delegation-Mechanism seems promising for the use in the process context, more specifically, in a PAIS.

With regards to business processes, Crampton et al. were the first to examine the satisfiability of workflow systems while delegating tasks [69]. Bakkali et al. [21] present an approach to bypass situations where obstructions occur by applying a specific delegation process, requiring a manual definition of potential delegates for the respected tasks. These delegates are selected according to their suitability, but may not have the necessary competence or expertise. The focus of the delegation from Bakkali et al., however, is on the task level. This leaves open to what extent a (secure) completion of the entire process is still possible.

#### **2.2.3.3 Changing the Policy**

The approach of Basin et al. [25], which was only briefly mentioned before, is now examined in more detail as an example for the type of approaches pursuing the change of policy with an unsatisfiable case at hand. Based on the distinction between administrable (e.g., RBAC), and non-administrable (e.g., SoD/BoD) authorization policies, it tries to solve an unsatisfiable workflow by changing only the administrable policies. The Enforcement Process Existence Problem asks, whether there is an obstruction-free enforcement mechanism that overcomes unsatisfiable workflows by reallocating roles to users at runtime such that the non-administrable policies are satisfied. Based on manually predefined costs of the risk of assigning a new user to a role, maintenance or administration costs, it is possible to determine the cheapest change of the authorization policy. Comparing this approach with the requirements from Section 2.1, the representation of the obstructed state is given only by the obstructed execution trace. It is the basis for finding the alternative policy. This alternative policy however only regards the authorization policy, not the constraints. Thereby, it might happen that an actually well-qualified user is not even considered to execute a pending task because she or he may be blocked by a "non-administrable" SoD constraint, and that a rather unqualified user is added to the role that allows to execute the task, no matter how "costly" this may eventually be. This is comparable to the risk in the approach of Bakkalili et al., where suitable manually predefined delegates that however may not represent the best options regarding competence or expertise are selected.

#### **2.2.3.4 Violating the Policy**

Crampton et al. [63] draw the same line of separation between the different policy types as Basin et al., namely authorization policies and constraints. So far, it has been the most sophisticated example of the approaches that allow for policy violation. As elaborated in Section 2.1, they aim to find the "least risky" user-task assignment for a workflow that is unsatisfiable. They assume that security constraints and usertask permissions can be violated, or overridden in order to complete a workflow. However, they allow to violate both, which results in a bi-objective optimization. In a further approach, there is also the idea of having a certain kind of budget what violations may cost, whereas the costs are still rather coarse-grained. However, with respect to the requirement of a comprehensive workflow structure, neither of the approaches considers loops or conditional branches. In contrast to Basin et al., they do not consider only the obstructed execution trace as input, but to some extent actually allow to model the obstructed state by changing the user-task authorization to singletons that contain the user who executed them, as depicted in Section 2.1. Despite limiting the representation of obstructability analysis result by not capturing all provided information in the obstructed state, encoding the obstruction with a simplification of the authorization policy also limits the set of possible solutions to resolve the obstruction as well, especially when loops are considered.

#### **2.2.4 Completability**

In summary, if it is not possible to avoid an obstruction, and given that an early process termination is not an option, ways how to still complete an obstructed execution must be provided. To give this idea a name, the term of completability is introduced. Completability can be seen as the consequence of obstructability. While obstructability is concerend with the detection of obstructions, completability focuses on the handling of obstructions in order to find solutions to complete obstructed execution. To formulate it as a question, completability asks: Given an obstructed workflow execution that resulted from the enforcement of a partial plan, is there a partial plan to complete the workflow that meets certain (security) requirements? In order to not allow such a solution to become arbitrary—one could trivially allow for completability by neglecting all security requirements— it is important that the question of completability depends on the requirements that such a solution should consider. The basic input for such a solution is given by the process specification that is used by the PAIS.

#### **2.2.4.1 Requirements for Specification-Based Completability (RSC)**

Based on the identified aspects and deficits, requirements for a specification-based approach to resolve and complete obstructions are identified. These requirements build upon the requirements stipulated in Section 2.1. In particular, a comprehensive process model structure should be considered for realistic obstructions at runtime. Further, the fact that runtime obstructions usually need to be handled immediately underlines the necessity to allow for efficient techniques. In the following requirements for the completion of obstructions, further references are made to the requirements of preventive analysis.

**Obstruction-resolving enforcement (RSC-1):** An important research direction is the avoidance of obstructions, which strongly bases on the findings from preventive analysis. There are several approaches that aim to provide obstructionfree enforcement mechanisms for which satisfiable plans can be used to ensure an obstruction-free enforcement, which is why the synthesization of runtime monitors is proposed. Despite their focus on prevention, in case of an obstruction, the monitors for obstruction-free enforcement are helpful as well to enforce the resolution of an obstruction. In case an obstruction needs to be fixed, obstruction-free enforcement mechanisms could focus on partial plans that complete the process, starting from the obstruction. In this respect, also plans that involve the least risky assignment regarding violations can be considered. The capability to enact such plans is also reflected in the aforementioned possibilities given by a PAIS.

**Security-sensitive Overrides (RSC-2):** Despite the identified deficits of Break-Glass approaches, foremost in not considering the existing policy, the general idea to allow to break out of an obstructed state and thereby taking violations into account is also helpful for the handling of obstructions. Further, the idea of Break-Glass to require subsequent inspection of the affected case can still be implemented in more security-sensitive approaches as well, as a means to further improve security. A PAIS can provide such additional mitigating techniques to prioritize audit of the affected case. Hence, there is a need for security-sensitive overrides that take violations of the policy into account. Based on the findings from the requirements from Section 2.1, costs can be used for such an assessment of security-sensitivity.

**Automatable Delegation (RSC-3):** Although classic delegation is more securitysensitive than Break-Glass approaches because it at least considers a responsible delegator with enough expertise to choose and an appropriate delegatee, it requires a high administrative effort, for example, the availability of the delegator, and involves fraud risks as well. Therefore, there is a need for an automated delegation. Technically, if a security-sensitive alternative assignment is computed, for instance with cost-based approaches, its enforcement can be regarded as the enforcement of an exceptional temporal security policy, which is comparable to a temporal delegation of rights as well.

**Obstruction-Aware Completability (RSC-4):** The question of completability of an obstructed workflow depends on the information provided to describe the obstructed situation at hand. In this respect, the existing cost-related approaches that allow for completion of an unsatisfiable case are only able to take the obstructive situation into account to a limited extent. For example, Basin et al. consider only the obstructed execution sequence, Crampton et al. in parts shrink their policy to capture the obstructed state, whereby information for computing a solution is lost. Because the existing approaches do not allow taking the "full picture" of how the obstructive situation arose and only assume a limited representation of an obstruction, it is in turn not possible either for them to offer a solution that takes full account of the course of process execution until the obstruction occurs. The identified requirements from Section 2.1 already attested that the overall state of obstruction in a PAIS must be captured in a better way, including all available information. In turn, this builds the foundation to handle and complete an obstruction adequately because the more information is provided, also the "better" and more security-sensitive solutions can be. Hence, to resolve an obstruction, there is the necessity for an approach that is fully aware of the obstruction.

In conclusion, obstructions at runtime need to be handled. The conflict between the workflow and policy enforcement is to be captured and resolved. Based on the enumerated requirements, to address the deficits of overriding, delegating or aborting the process, this thesis caters to find optimal partial plans, such that eventually, the obstructed case can be completed in a security-sensitive way. To allow for completeability, a PAIS can then enforce such an obstruction-resolving plan to steer the process towards its completion. It therefore requires an efficient automatable approach that allows a violation of the policy while taking the requirements from the preventive analysis, in particular, an extensive representation of the state of obstruction and a comprehensive process structure, into account.

#### **2.3 Detective Process Analysis: The Case of Obstructability by Incompleteness**

The detective analysis is related to the "evaluation" phase of the BPM lifecycle and focuses on the recorded process executions. As examined in Chapter 1, process automation goes along with the magnitude of data that is generated in the course of digitization. More specifically, the enterprise information systems (regardless of whether process-aware or not) generate data while the processes are executed, such that in some form, the execution of the process is recorded. According to Bishop [33], logging is "the recording of events or statistics to provide information about system use and performance". Given a PAIS, process executions can be recorded and captured in a process log. Each activity that executed a task of a process is recorded as an event that can be assigned to an instance of a process or a case. Such recorded cases, namely the recorded sequences of events, are represented as traces, which constitute the overall process log. Analogously to the process model, a log captures different dimensions as well, for example the control flow or the organizational perspective. The research discipline that builds upon this process entity is captured under the notion of process mining [3]. Detective analysis subsumes not only detective monitoring but, more generally, auditing, which, from a general computer security perspective, is "the analysis of log records to present information about the system in a clear and understandable manner" [33]. Hence, it can be used as a posteriori technique for determining security violations. Whereas detective monitoring implies that a potential action is taken timely, the reaction time for auditing can be significantly longer. However, the execution traces of the process are regarded in both cases. Based on the given trace properties, such process executions can be analyzed as to whether (and how) the designated business goals are achieved (liveness) and whether policies were adhered to (safety). Hence, whereas the so far regarded literature mainly covers safety properties and the implications of their enforcement, logs additionally provide the possibility of checking for liveness properties. In particular, they allow to consider completed "closed" cases, which allow to assess if liveness properties were indeed "eventually" fulfilled. Regarding the observation of obstructions, this is mainly interesting for property of completion, for example if an end activity could be reached. If this is not the case, the obstructability of the process involved is indicated by incompleteness, i.e., traces that do not represent completed executions due to obstructions.

In general, the main difference to the modeling and specification of a process is that the log actually represents how the process was actually executed, or "how it was lived". In contrast, a process model rather aims at a comprehensive view of a process and generalizes individual cases of the real world process [40]. The basis for the WSP builds the process model and policy specification. Nevertheless, the use of logs for satisfiability, resilience and obstructability research can be wellmotivated because there are manifold reasons to use their so far untapped potential, for example: Regarding the WSP, the log can help to assess to what extent specific satisfiability problems are actually relevant, such that it is able to investigate the importance of individual paths of a workflow. Regarding resilience, besides assessing the importance of specific paths and its relevance, the log can reveal the probability of a user to be available. The log further offers the possibility to simplify the computational complexity the computation because it represents a finite set of events and traces. Regarding the computational complexity, because a log represents a finite set of events and traces, if it is replayable on a model, to identify if, for this finite set of traces, it is still satisfiable. Thereby, loops would be restricted to the finite set of realistic events given by the log. This may, for instance, give insights on how changes to policy design impact the conduct of the lived process. Regarding obstructability, at first sight, logs in fact "limp a step behind" in handling obstruction during runtime. However, they provide a basis to learn from completing obstructions. On the one hand, a log contains obstructed executions which manifest themselves in an incomplete or aborted trace that can result from an obstructive policy design or exceptional user absence situations. On the other hand, the log can contain complete and successful traces, or is even able to document how an obstructive situation has been resolved. Regarding the latter, depending on the flexibility a PAIS allows, or, in other words, how strictly it insists on adherence to the control flow, the log reveals important and practically relevant insights, which may differ from the control flow of the model, for example because further contextual factors beyond the model and specification were taken into account. That way, the log may encompass completed traces that represent compliant behavior that deviates from given security policies and properties. Further, a trace of a completed execution that involves violations may also result from a Break-Glass scenario, which, however, may have been checked by audit and was subsequently assessed and marked for being without concern. In this case, also the log would capture behavior of completed, compliant executions that deviate from the initial process specification. The log may further be useful if an information system does not support the modeling and enforcement of authorization constraints. Indeed, the lack of controls during runtime, as show in Chapter 1 (cf. ACFE results), is often reflected in the fact that preventive controls are not always used due to the associated costs and the sometimes negative effects on process execution. The risk of deviating execution paths is accepted and the compliance check is shifted to audit analyses. Although there are attempts to integrate monitor synthesis techniques, such constraints are often specified separately and handled by auditing software (cf. CSI tools), whose main goal is to detect problems a posteriori. However, even in case of no control and authorization enforcement during the execution, logs are of beneficial use. An actual obstruction during process execution would then not block the process. The involved users may, however, be aware of an actually obstructive situation based on contextual information (e.g., known regulatory rules). After extracting the data of such a system into a log-file, a subsequent analysis of the respective log is able to reveal if such a situation was at hand and how it was handled, namely if the process was blocked, aborted or if there was some way to overcome an obstruction. The log would then give insights to indicate weak spots of the process, for example risky or failing workarounds. On the other hand, this could also reveal successful workarounds, which may even help to resolve and guide other obstructive situations. Thereby, a user who is aware of an obstructive situation could, for example, be assisted by a system that recommends how to proceed, based on the insights provided by the log.

These manifold reasons further reveal that it seems natural and beneficial to differentiate between successful and obstructed log executions, which can be done, for example by analyzing the liveness property of process completion. This allows to reason on the causes of successful executions and even to guide a log-based handling of obstructions. Moreover, the log allows to derive further indicators, for example, Resource Behavior Indicators (RBI) [164] or indicators that are used in predictive monitoring [143], which helps in assessing the risk of violation in case of an obstruction and can enrich the process model. Such information improves the overall level of information how to handle and complete obstructions.

While most of the so far regarded related work is aimed at theoretical preventive observations, the use of logs for a practical application to approach (un)satisfiability is hardly ever considered. As far as known, there is only one further approach that relates logs and process mining to the extended context of the workflow satisfiability problem [52]. It is used to preprocess and reconstruct a control flow model such that a user subsequently defines the policy on top, which, however, represents a different focus than this work does. This is the first work that aims to use logs for the analysis and handling of obstructions. Taking "real" runtime obstructions and "real" solutions into account stresses its practically oriented focus. For this, this chapter will systematically draw potentials from the use of logs regarding obstructability. Based on the possibilities of process mining, general ways of how logs can be used beneficially to analyze and resolve obstruction will subsequently be identified. After a short look on event logs, these possibilities will be identified and elaborated further along the threefold disciplines of process mining, namely process discovery, conformance checking and enhancement. Finally, the potentials and requirements for a log-based approach will be deduced.

#### **2.3.1 Process Logs**

When a process is supported by information systems, details of the execution of the process are generally available in the form of *event data*. Although PAISs directly provide event logs, as mentioned before, there are many information systems that store such information in unstructured form (for example databases), such that event data can be distributed over many tables or need to be retrieved from subsystems that exchange messages. In such cases, event data exist, but some effort is required to extract them, such that data extraction is an essential part of any process mining endeavor [3]. After getting and extracting the data, possibly from different sources,


**Table 2.2** Example DMV trace

these data take the form of an *event log*. Event logs represent the footprints left by process executions that were stored by an information system [3](e.g., a PAIS). As shown in Figure 2.4, they consist of a collection of *events* that record which activity for which case was executed. Thus, an event log depicts the recorded behavior of a process. Events can be distinguished by the cases in which the respective activities were executed. This results in event sequences, designated as*traces*. They represent the recorded behavior for the individual cases of the process. Table 2.2 displays an example of such a trace. Accordingly, a trace is a recorded representation of a case of the process, analogously to an execution sequence of a process model, which is a modeled representation of a case [40]. This section takes a closer look on process logs, in particular on what they are able to capture, and which ways are offered to detect obstructions.

#### **2.3.1.1 Formats**

Event logs are the core ingredient for process mining algorithms. They exist in different formats. After the Mining eXtensible Markup Language (MXML), its successor, the XES format, was established. XES is an a XML-based format for the interchange of event log data between tools and application domains, which is approved by the IEEE as the Standard for eXtensible Event Stream (XES) for Achieving Interoperability in Event Logs and Event Streams (1849-2016) [115].

**Figure 2.9** Standard transactional life-cycle model [3]

Analogously to the described basic structure, an XES document represents an XML file and contains a log consisting of any number of traces. Each trace describes a sequential list of events that are assigned to a particular case. The log, its traces, and its events can have any number of attributes that can be nested in each other. No fixed set of mandatory attributes is required for each element (log, trace, and event). However, to provide semantics for such attributes, the log refers to so-called extensions. Each extension can define attributes that are considered standard when the extension is used. XES can declare certain attributes as mandatory fields. For example, it can be specified that each trace should have a name. Thus, not every possible attribute must be contained in a log [3]. In logs of higher granularity, different information on the state of an activity execution can be captured as well. This transactional information on activity instances can have different state attributes according to the standard transactional model, which is displayed in the state machine in Figure 2.9. These are of considerable interest when filtering the log for potentially obstructed or completed traces in the sense of unsuccessful or successful traces respectively.

```
1 <? xml version ="1.0" encoding="UTF -8" ? >
2 <log xes. version ="1849.2016" xes.features=" ">
3 <extension name="Concept" prefix="concept" uri="http://.../
     concept.xesext"/ >
4 <extension name="Organizational" prefix="org" uri="http:
     //.../org.xesext"/ >
5 <extension name="Lifecycle" prefix="lifecycle" uri="http:
     //.../lifecycle. xesext"/ >
6 <global scope="trace">
7 <string key="concept:name" value=" "/ >
8 </global>
9 <global scope="event">
10 <string key="concept:name" value=" "/ >
11 <string key="org:resource" value=" "/ >
12 <string key="lifecycle:transition" value=" "/ >
13 </global>
14 <classifier name="Resource classifier" keys="org:resource"/ >
15 <classifier name="Activity classifier" keys="concept:name
     lifecycle:transition" / >
16 <string key="concept:name" value="DMV Log"/ >
17 <trace>
18 <string key="concept:name" value="22"/ >
19 <event>
20 <string key="org:resource" value="System"/ >
21 <string key="lifecycle:transition" value="schedule"/ >
22 <string key="concept:name" value="Compute Market Value"/ >
23 </event>
24 <event>
25 <string key="org:resource" value="Alice"/ >
26 <string key="lifecycle:transition" value="start"/ >
27 <string key="concept:name" value="Compute Market Value"/ >
28 </event>
29 <event>
30 <string key="org:resource" value="Alice"/ >
31 <string key="lifecycle:transition" value="complete"/ >
```

```
32 <string key="concept:name" value="Compute Market Value"/ >
33 </event>
34 <event>
35 <string key="org:resource" value="System"/ >
36 <string key="lifecycle:transition" value="schedule"/ >
37 <string key="concept:name" value="Control Computation"/ >
38 </event>
39 <event>
40 <string key="org:resource" value="System"/ >
41 <string key="lifecycle:transition" value="pi_abort"/ >
42 <string key="concept:name" value="Control Computation"/ >
43 </event>
44 </trace>
45 <trace>
46 <string key="concept:name" value="23"/ >
47 ...
48 </trace>
49 ...
50 </log>
```
**Listing 2.1** XES example of DMV trace

Listing 2.1 shows an XES version of a further example case of the DMV process. Here, the organizational extension defines a resource attribute of type xs:string (e.g., for "Alice"). Further, this log also provides the lifecycle extension that allows to represent the status of each activity execution. In this way, the process abortion that occurred in case 22 can be documented (see line 41). Hence, depending on the information recorded during process enactment, a log file is able to capture obstructed and successful traces in different levels of detail.

#### **2.3.1.2 Filtering**

It is common practice to filter the logs before applying process mining techniques. Filtering is basically first used to clean up the log so that it does not contain any erroneous traces, for instance, by minimizing the noise [40]. There are systematic approaches to identify noise patterns [192] as well as to filter and clean event data [53, 205]. In this respect, the term of "incomplete logging" is also related to errors that happen during the recording of process data, for example missing activities distributed along the entire process execution. It is important to note that the aim to filter traces that are incomplete—in the sense of not completely executed represents a notion of incompleteness that should not be confused with the term "incomplete logging". In this context "fragmentary" or "gappy logging" would be a more differentiated description of what is often meant by "incomplete logging". In contrast, in the sense of an obstructed execution, incomplete means "not completed", with respect to the flow of activities, and is an error-free recording of a partial trace.

**Endpoints Filter:** A log usually represents an excerpt from the system log over a certain period of time. Due to this selected time period, there may be incomplete traces whose start or end activity lie outside the selected scope. It must therefore be ensured that traces whose beginning or end are "cut off" are filtered out as well. In this respect, for example, the so-called "endpoints filter" allows to determine what should be the first and the last event in a process case. With regard to the identification of obstructions, given a basically filtered trace that does not contain any traces that were cut off due to the selection of the log interval anymore, the endpoint filter is still of interest. It can also be used to filter traces that fulfill the liveness property of process completion scanning the traces with regards to the occurrence of an end event. That way, if the end activity that distinctively characterizes a completed process is known, complete and incomplete traces can be separated. However, this does not necessarily mean that incomplete traces are also obstructed traces. Therefore, in order to increase the likelihood of actually filtering obstructed traces if a log provides more detailed information, further and more fine-grained filtering can be conducted.

**Attribute-Based Filtering:** Based on the attributes given by the XES standard, further fine-grained filtering can be done in order to split the log into aborted or completed cases. As indicated in Listing 2.1, the transactional model provides state attributes that allow to indicate that a case or process instance was aborted (cf. abort\_case or in XES:pi\_abort (see line 41)). Further, an activity that was only "scheduled" (see line 36 in Listing 2.1), but has not been assigned yet can indicate an obstruction as well, when the assignment was not allowed due to the policy or when it was not possible due to unavailable resources. Filtering traces in this way, is a first indicator that incomplete traces were actually aborted due to an obstruction. Conformance checking, which will be highlighted as a process mining-method in the next section, is able to go one step further. For example, based on the given policy, it is able to indicate if SoD conflicts were involved within an aborted or only scheduled case. This would exclude cases that were aborted for other reasons, for example system failure, and it would substantiate the suspicion that the regarded traces were indeed obstructed due to the enforcement of safety properties.

To conclude, filtering in its common application is often used, for example, to select only the most frequent event logs in order to simplify the application of subsequent process mining methods and to lighten their computation and to strengthen the significance of the results in the light of a specific question. This whole process has an iterative nature because process mining results most likely trigger new questions and these questions may lead to the exploration of new data sources or more detailed data extractions. Typically, several iterations of the extraction, filtering, and mining phases are needed. In this context, the underlying questions of Process Mining can also be seen from a business intelligence perspective [3]. A concrete question is addressed to the logs, for example, how the process performs, whereupon the log is filtered against this question and analyzed. The same applies to the use of logs in the security context, or in the sense of this thesis in identifying and dealing with obstructions. The following methods of process mining will be introduced briefly, but will then be specifically considered with regards to their possible advantages for the detection and handling of obstructions in security-aware workflows.

#### **2.3.2 Process Mining**

Process Mining addresses both processes and data, which are fundamental elements of digitization. It is therefore a fairly young research discipline, and can be located between machine learning and data mining on one side and process modeling and analysis on the other. The basic idea of Process Mining is to discover, monitor and improve real processes (i.e., not assumed processes) by extracting knowledge from event records that are easily accessible in today's systems [3]. It can essentially be subdivided into three disciplines, as shown in Figure 2.10. This section presents a brief overview of the process mining methods and relates it to process security and obstructability.

#### **2.3.2.1 Process Discovery**

Process Discovery has the goal of discovering a process model based on logs without the use of any a-priori information. If the event log provides further information, for instance about resources, it is possible to discover resource-related models, such as a social network that reveals how people work together in an organization [3]. Discovery approaches that are related to security aim to reconstruct models that are as precise as possible, to not rule out possibly rare but important deviations that involve suspicious facts and indicate violations [189]. Challenges here are clearly the aforementioned incompleteness or noise, which affects the log but represents behavior that did not actually happen. Regarding obstructions, this challenge also applies for the distinction between erroneous/incomplete and uncompleted (in the sense of unsuccessful) executions.

Hence, given that noise and error are eliminated, analyzing a discovered model allows to reveal unsuccessful executions, for instance, remarkable paths in the model that noticeably skip the usual activities and come to an abrupt end. On the other hand, based on previous filtering, the discovery technique can focus on successful

**Figure 2.10** Positioning of the three main types of process mining: discovery, conformance, and enhancement [3]

executions, such that the discovered model of successful traces is used to identify obstructions or to show which paths there are to avoid or even handle them. Such comparisons of log and model already belong to the subsequent type of process mining.

#### **2.3.2.2 Conformance Checking**

Conformance checking bases on a discovered or a manually defined model. It compares a process model with an event log of the same process and can be used to confirm that the reality recorded in the log is consistent with the model, and vice versa. For instance, the SoD constraint states that the computation of the market value and its control need to be done by two different people. By scanning the event log using a model that defines this requirement, a violation, and thereby, potential fraud of the actors involved in the found traces, can be detected. Therefore, conformance checking can be performed to identify, detect and refine anomalies and measure their severity [3]. Checking for security properties may therefore be performed by means of conformance checking. Clearly, as a basis for a precise analysis of security requirements with conformance checking, process discovery also need to be precise to capture important security aspects, for example deviations, as well, and to not rule out possibly rare but suspicious paths that indicate violations. More specifically, based on the comparison of model and log, there are three general so-called conformance checking artifacts, which indicate consistent and deviating parts: rule checking, token replay, or alignments. The indicated example on SoD represents such behavioral rules, which are defined by the model and violated by some traces of the event log. As to the replay, events of traces can either be replayed by task executions in the process model, or the replay fails. An alignment tries to "align" events from a trace of the event log with the task executions of an execution sequence from the model [40].

**Identifying Obstructability ex-post:** Because the traces in the log represent the actual behavior how the process was lived, the process log can be depicted similarly to the overall behavioral scope in Figure 2.14. Conformance checking can then be illustrated as drawing the lines in an unclassified behavioral scope given by the log according to given requirements such that, for example, the secure, compliant and non-compliant areas are identified. The separation of consistent and deviating parts with regards to certain requirements can be used to separate successful and obstructed traces as well, which allows to reason on the obstructability of the process and how it is handled. For example, by checking if there are traces in which a liveness property, for instance, a finalizing activity, is missing (rule checking), by replaying traces on a model to indicate non-replayable and potentially obstructed traces, or, in a more fine-grained way, also alignments can be used to indicate successful and obstructed traces. Alignments can be assessed against different metrics, most prominently fitness and precision. Fitness investigates how much behavior of the log is captured by the model, precision asks how accurate the model describes the log. Depending on the granularity of the log, successful traces can also be traces that only come close to the model, but still represent a complete execution. Here, execution sequences based on a model that addresses the requirements stipulated for the preventive analysis in Section 2.1 may increase the significance of the alignments computed with a given obstructed trace.

The identified categorization and separations in the Process Mining context can build the basis for further analysis. For example, by identifying traces that do not reach the end of an execution, indicators on possible related problems can be investigated in comparing them to successful ones. Clearly, based on such a separation, discovery techniques can identify a successful and an obstructed model to identify problems in the process or policy specification as well.

#### **2.3.2.3 Enhancement**

Enhancement represents the third type of process mining. Its overall idea is to extend or improve a process by using information about the actual process recorded in some event log. On the one hand, the model or the log can be repaired (i.e., improved), based on the findings of discovery or conformance checking. On the other hand, the model or the log can be extended or enriched with further information based on such and further findings. Repairs or extensions can also be intertwined and work in both directions, the log improves and repairs the model, and vice versa. Log enhancement can therefore enrich the events of a log with additional information, which can then be used for further techniques for a log-driven analysis of the regarded process. Such information originates from a process model or some analysis conducted based on a process model, for example, using the labeling of activities with responsible roles or the probability to complete the process. The enhancement of the model enriches the model based on the log, which enables further types of model-driven analysis. A typical example is, if two activities are modeled sequentially but can happen in any order in reality, the model is corrected to reflect this [40].

Extension can mean adding a new perspective related to the log. A prominent example is the extension of a model with performance data. For instance, by using timestamps in the event log, one can extend the model to show bottlenecks, service levels, throughput times, and frequencies. In particular, the model can be enriched with the duration of the activity executions, such that a distribution is fitted to the execution times recorded in the log per activity. This information enhances the process model and, for instance, enables performance simulation and prediction. In this way, logs can be used to tackle the gap of not knowing what is going to happen next in the process execution and they can help in better defining probabilities that certain events occur. Further, a model can be extended with information about resources, decision rules, quality metrics, etc. [5].

Hence, regarding this thesis, on the one hand, "extensions" seem useful to enrich models or logs, thus enabling the required indicators to be taken into account. On the other hand, "repairing" also offers interesting approaches, which are beneficial for the completion (or "repairing") of obstructed executions.

**Extensions to Capture Indicators:** Extension, in particular the extension of the model, are of interest for the consideration of an indicator-based security. Here, it is of interest to mainly consider security relevant indicators. There is a wide range of indicators that can be derived from logs [17, 164, 165]. Besides, the prominent Key Performance Indicators (KPIs), mining resource profiles and related indicators have raised a lot of interest in recent years. Regarding this work, the Resource Behavior Indicators (RBIs) are subsequently sketched as a particularly suitable example because resource behavior is also relevant for security and completability. Different taxonomies cover the different behavioral aspects of resources, which are exemplified in Figure 2.11.When it comes to resilience, satisfiability and obstruction resolution, user reliability can, for example, be considered as an important factor to assign the most reliable users to an already "ailing" execution in order to ensure its completion. Such a reliability indicator lessens the risk that an employee is likely to be involved in security violations. That way, the process model can be enriched with indicators that preferably assess policy violations and the associated risks.

Ultimately, the computation and the weighting of different indicators can result in a final number expressing the overall risk. This can be done not only with regard to the users but also to the tasks to be performed. A model which is able to capture these indicators would create a framework for an indicator-based security and would enable a security-sensitive and differentiated view on violations.

**Repair: Fixing the process specification:** In general, repairing can be understood in the sense of repairing the model such that it better reflects reality. On the one hand, repairing can be useful for policy designers who want to fix obstructions on the basis of the insights from process mining. Based on the separation into successful and obstructed logs and further conformance checking, weaknesses in the specification, for example, in policy design, can be uncovered. Further, if certain risky paths that allow obstructions do not occur in the log, the process designer may consider

**Figure 2.11** Using logs to deduce resource indicators [17]

changing or adapting the model. For example, it is possible to repair an SoD policy in a way that makes the overall policy more restrictive and thus prevents obstructions during the execution by design. To do this, two activities for which an SoD conflict exists can be assigned to only different users, so that no user is authorized for both activities at all (which would, however, negatively impede the flexibility of the process execution). In a broader sense, repairing may also be understood as the fixing of an obstructed path in the model, such that based on the log, either the path is changed, or it is extended such that it can still be completed.

Based on the log that contains successful executions and an obstructed trace, the question is how this trace can be repaired such that it is completed with minimal violation. Repairing can also be understood as a repair at runtime, where the question would be how an obstructed execution can be completed. It is then not a question of repairing the whole model, but only an execution sequence or a case. In this respect, a further distinction of process mining is introduced, regarding the point of time of its application, namely online and offline process mining.

#### **2.3.2.4 Offline and Online Process Mining**

The traditional way of using process mining is offline. This means that only closed cases are taken into account, that is, the event log contains complete traces corresponding to the cases completely processed in the past. However, for operational support, for example, the handling of obstructions during execution, it is necessary to consider "live" event data and to provide an online response to these data. The basic idea here is to only consider cases that are currently still running, because these can also be influenced and still generate events. They are described by partial traces [3].

The basic setting of these online process mining approaches is that there is some partial trace of a running execution. Based on that partial trace, an operational support system considers insights from the log to find violations or make predictions and recommendations (cf. Figure 2.12). In particular, the log is used to learn a normative, predictive or recommendation model, which then builds the basis for the operational support system to put the given partial trace into the perspective of past executions. Interestingly, this basic setting is comparable to the basic situation of this thesis in handling obstructions. On the one hand, there is a partial trace that is obstructed, and on the other hand, the approach is supposed to provide, in a sense "predict" or "recommend" a security-sensitive partial trace to still complete the execution. Various techniques can be used to generate predictions, for example, techniques from supervised learning. On the basis of the information contained in the partial trace and a prediction model, predictions can be derived, for instance, regarding a KPI such as the remaining flow time or the expected total costs. The predictive model is based on historic event data, but can be used to make predictions for the cases that are still running. Recommendations base on predictions as well [3].

**Figure 2.12** Recommendation [3]

Instead of focusing on the model and the policies for the execution monitoring as done before, logs can also be used to check executions in terms of a monitor. Thus, not only the preventive analysis, but also the detective view can be used as a basis for monitoring. Here, the previously identified detective monitoring comes into play. It is related to process enhancement in a sense that the process is extended with additional information, but discovery and conformance checking can also be involved. Therefore, predictive monitoring will be introduced in the following.

#### **2.3.2.5 Predictive Monitoring**

A sub-discipline of online process mining that is particularly noteworthy against the background of this work is predictive monitoring. Predictive business process monitoring techniques go beyond traditional ones by predicting quantifiable metrics about the future state of the running instance of a business process (i.e., the cases) [143]. There are different questions that want to be predicted: What will probably be the next activity that will be executed? Will there be violations in the execution? How long will the overall process take or will the remaining time stay below a certain bound (e.g., for a loan application)? Or, what will be the results of the process (e.g., will a client purchase an item or not, or more generally, the achievement of the business goal)?

More specifically, as depicted in Figure 2.13, predictive monitoring assumes a partial trace for which predictions about the future can be made on the basis of the process log. The event log is the input of these methods and provides the necessary characteristics that define the process for the prediction. The predicted value represents the output of these methods and applies either to the current process instance or to a collection of instances. Depending on the target of the prediction, this

**Figure 2.13** Predictive Process Monitoring [203]

value belongs to a particular domain and can be numeric (e.g., the remaining time of a process), Boolean (i.e., regarding an outcome, e.g., the fulfillment of a particular goal), or categorical (e.g., regarding a user) [144]. Related literature objects to predict a wide range of values, among which are time, foremost remaining execution time , the prediction of the next event in the given case [91, 166, 195], an estimation of the value of a single indicator or an aggregate attribute, LTL formulas, which determine the occurrence of a certain situation in the process, or the risk probability (e.g., the violation of a constraint or abnormal termination) or in general, the final outcome of a case with respect to a possible set of business outcomes [81, 84, 85, 143, 149, 150]. Regarding the latter, each running case of a process can be classified according to a given set of possible categorical outcomes [202]. For instance, a possible outcome of a case may be that a collateral evaluation is finally completed (e.g., the acquisition was finally approved). On the other hand, it could also be closed unsatisfactorily (e.g., the evaluation was aborted and the process goal was not reached). Another further outcome that could be considered would be if the collateral evaluation was performed in a specific time (with respect to a maximum acceptable waiting time for the overall process). Predictions can be used to alert process users to problematic cases or to support the assignment of resources, for example, assigning additional resources to risky instances [144, 201]. Hence, such an outcome may be the fulfillment of a compliance rule, a performance objective (e.g., maximum allowed cycle time) or business goal, or any other characteristic of a case that can be determined upon its completion.

**Predicting Obstructions:** The questions of predictive monitoring can be related to the question of obstructability:Will the process be successfully executed or will it get obstructed? Will there be enough users to execute the process? Will the current partial trace be obstructed in the course of its continuation due to missing authorizations or can the case even come to an end? Or, will a positive outcome of an obstructed execution be achieved? The similarities of questions make predictive monitoring particularly interesting, especially the outcome-oriented version. Particularly, predictions on the outcome in terms of fulfillment or violation of security properties can be performed. Further, the prediction of the process termination can determine the probability of the fulfillment of a liveness property. In the sense of operational supports, such an online on-the-fly conformance checking can not enforce liveness or safety properties, but allows to check them very promptly. Thus, even if, as previously explained, liveness can not be enforced in the classical sense, one can at least increase the probability of the fulfillment of liveness properties with corresponding prediction or recommendation methods. In this respect, the log may give insights on which sequences involving which actors and which activities are most likely to succeed. Therefore, an estimation can be made, which allocation of users to tasks will probably also "enforce" process termination. In turn, also problematic execution paths, for example due to unsatisfiable policies, could be identified, for example by relating the possible paths to their rate of completion.

**Recommending Obstruction Resolution:** From the view of the handling of obstructions, similarly to previous observations in this chapter, the fundamental deficit of the current approaches to predictive monitoring is the tendency that they are basically "avoidance approaches" as well. Prediction techniques are used to avoid undesired states of the process, e.g., security violations, or also obstructed process executions. For example, there are techniques to maximize the probability that a process execution satisfies all constraints, or, to identify if it is likely that a possible execution path takes too long, such that another path with a better prediction can be chosen. Hence, this can be compared to the goal of preventive analysis, which tries to avoid unsatisfiable workflows, or the enforcement of obstruction-free authorizations during runtime. Indeed, to some extent, predictive monitoring can be compared to the approach during runtime to use synthesized plans, to guide and predict the execution of a process in terms of following an obstruction-free path. The question is to what extent a predictive monitor really enforces its predictions, which is comparable to the obstruction-free enforcement mechanisms presented before, or if obstruction-free predictions are only recommendations such that the user may eventually choose which path to follow. Because predictions also allow for proactive and corrective actions to improve process performance and mitigate risks, the so-called "prescriptive process monitoring" goes one step further. Prescriptive process monitoring not only wants to predict that process executions may result in an undesirable process state such as a security violation but also seeks to prevent this. It extends the scope of purely predictive systems by not only generating predictions but also advising users in case of an instance being likely to lead to an undesired outcome if and how they should intervene in an ongoing case. Such an undesired outcome can be prevented or mitigated, for example, by optimizing a given utility function [201]. However, prescriptive process monitoring still represents a rather observational procedure. It is still an avoidance strategy, albeit a more proactive one. The ideas of correction and intervention are rather meant to influence the development of process execution on the basis of predictions in such a way that the defined goals can be achieved as far as possible, which can only happen within the scope of action set by the process model. Further, as the name suggests, prescriptive monitoring additionally "prescribes" in advance how to react to possible undesirable developments and defines key indicators or thresholds, which should alert the responsible users in case they are exceeded, so that they can then take corrective action according to the correction prescribed in advance. It is not considered to "touch" (or even violate) the process specification. The questions of what to do in the event of an actual process obstruction, and how obstructed traces are fixed, which, as explained, can occur despite all predicted probabilities, are not dealt with. Nevertheless, due to the comparability of the questions posed regarding obstructability, the methods of predictive monitoring seem promising to resolve obstructions as well. Due to the abundance of such methods, which is underlined in two recent literature reviews [144, 202], it is foremost a matter of showing the fundamental feasibility of the adaptation of the methods to the aims of this work. Predictive monitoring is therefore of considerable interest for the handling of obstructions; on the one hand regarding the indicators that are considered, on the other hand, regarding the approaches that are used to generate predictions such that they may inspire solutions how to complete an obstructed trace based on the log.

#### **2.3.3 Log-Based Completability Requirements (RLC)**

In conclusion, it has been identified that the log offers the potential to create a different approach to satisfiability, resilience and obstructability. Due to the lack of log-based techniques in the given context, this section on detective analysis has not identified deficits of existing techniques, but revealed potentials for the application of logs. Based on these observations and the observed potentials, log-based approaches should consider the following possibilities and requirements for the analysis and handling of obstructions:

**Detect and Separate Obstructed and Successful Traces (RLC-1):** In order to be able to use logs in the context of this thesis, it is necessary to have methods to separate obstructed traces from successful ones. This can be done by attribute-based trace filtering, with process discovery, in which an obstructed trace is captured in a path that bypasses other essential activities, or in a more precise way with the help of conformance checking. Thereby, logs can be separated in obstructed and successful executions. Based on this separation, an obstruction can be put into perspective. It is possible to assess the obstructability of the process, even if the process was not controlled by a PAIS during execution.

Obstructed traces can be used to identify deficits in the process specification. One can think of the reasons why the obstructed traces were obstructed to improve the process. Further, they can be used to assess the probability of a preventively detected obstruction to occur in reality. Successful logs can be used to guide how the policy is to be improved or for the completion of a running instance, for example, with success rates regarding an outcome in predictive monitoring, e.g., process completion, or by reasoning on how they might be used to complete partial traces. Further, a discovered model based on the successful logs can guide the completion in case of an obstruction as well.

**Identifying and quantifying indicators: Assign Costs Based on Log (RLC-2):** As identified, the log can be used to identify manifold indicators. Methods of filtering and conformance checking but also process enhancement and predictive monitoring can be used for this. These indicators can then be considered and used to determine an execution sequence that can complete an obstructed execution as security-sensitive as possible. This, in turn, underlines that the model must be able to consider costs, such that quantifiable indicators can actually enhance it. In the light of the requirements for a representation, as specified in Sections 2.1 and 2.2, the extension of the model with further information has similarities to the previously identified requirement to consider costs, for example in finding executions scenarios for satisfiable processes. What would be new here, in contrast to the costbased approaches shown in the previous sections, is that the model would directly be extended with the costs. Hence, the need to capture costs, was now determined before, during and after execution as a requirement for all approaches.

**Proposing measures: Finding paths to complete obstructions (RLC-3):** How does a log-based approach need to be designed to not only detect but to provide measures to complete obstructed executions? As identified, logs can also be used to recommend actions based on the behavior they reveal. This generally meets the approach of this thesis on how to deal with obstructions, so that the basis for the required rational decision is extended with data. Here, although online-process mining has a similarity to the handling of obstructions during execution monitoring (cf. Section 2.2), the log-based approach has not yet been considered for the handling and completion of obstructions. Therefore, methods already used in predictive monitoring are meant to inspire solutions to resolve obstructions. In particular, among other goals, predictive monitoring uses logs to complete processes (as a positive outcome). This and involved log-based techniques represent a starting point to resolve obstructions as well. Here, first and foremost, the basic practicability of using logs to resolve obstructions needs to be shown.

To conclude, this work is meant to also consider logs to unleash their potential in detecting and handling obstructions. There are manifold ways to separate completed traces from obstructed ones, for example by analyzing safety and liveness properties. Based on this, it is possible to derive meaningful indicators, which can be considered as costs when solutions are calculated for an indicator-based security. These costs can then be incorporated in the representation required in Section 2.1 and 2.2. Here, completing obstructed traces, in particular the adaption of methods provided from predictive monitoring seems promising to actually tackle obstructions based on logs. Such a completed trace would possibly violate a safety property such as an SoD requirement, but would eventually allow the liveness to be "enforced". Depending on the information system that is used to execute a process, the policy or process model is not necessarily enforced and it may happen that only logs are available. Therefore, the log-based approach should stand for its own, but at the same time it should be able to be used to complement the specification-based approach.

#### **2.4 Security-Sensitive Detection and Handling of Obstructions**

The previous sections of this chapter identified that engineering methods that can handle unexpected process "obstructions" is a hardly touched research field. However, it is very relevant in practice, because it contributes to the construction of reliable, secure enterprise information systems [8].

There are different research directions ultimately trying to improve and finally avoid an obstructive state. Besides the extensive research, which has been conducted with respect to the analysis of satisfiability and resilience before process execution, mainly research topics concerning the enforcement of obstruction-free executions or other forms of an avoidance of obstructions were identified. Interestingly the previously identified nature of classic IT security comes to light in this, i.e., an obstructive state is rather avoided than handled. This can be illustrated with the help of an exemplary allocation of existing approaches to the behavioral space. Obstructive situations mainly originate from applying classic IT security to workflows. Figure 2.14 indicates the restricted behavioral space of satisfiable workflows, and the even more restricted scope of resilience (for example for k=1). Obstruction-free behavior corresponds to the secure behavior or is even restricted further. Hence, similarly to these indicated two areas, a big part of existing research mainly has the tendency to even further restrict the behavioral scope. Research on related notions focus on keeping the secure state, across all process entities. As for the use of logs,

**Figure 2.14** Process behavior sketching completed satisfiable executions reaching end state (no outgoing arc) and k-resilience (with k=1, i.e., one absent user)

predictive monitoring equally aims at avoiding unwanted outcome (e.g., avoidance of non-completing paths). All such approaches act in the frame set by classic security. Before the execution these avoidance-techniques definitely make sense because the obstructive situation is not there, and they can be used to improve process or policy design and detect design flaws. Taken together, classic WSP research operates in the frame set by IT security as well and only a few other approaches consider a security violation. Interestingly those who do so actually assign costs to policy changes or violations, which is somewhat in line with the required indicator-based approach to process security.

#### **2.4.1 Main Deficits in Obstructability Research**

Figure 2.15 shows the different entrepreneurial possibilities in avoiding or confronting and handling of obstructions. To actually handle obstructions, there is a need to extend the behavioral scope in the sense of the paradigm shift that is meant to work with an indicator-based security, i.e., to allow the handling of obstructions in the frame set by compliance (see cross-hatched area in Figure 2.15). After each subchapter identified requirements for preventive, runtime and detective approaches, the main deficits regarding the detection and handling of obstruction will be highlighted and summarized. This allows to put the solutions of this thesis into a more comprehensive framework.

Despite the need to automate regulation, as identified in Chapter 1, this chapter identified that there is no automated or semi-automated security-sensitive solution to obstructions. Although there are approaches with this intention, they often only exist as first concepts, and aim to change policies, or even override them without taking them into account (e.g., Break-Glass).

Although delegation does not totally override policies, it involves the risk of collusion and requires the availability of a delegator. Here, automating delegation seems promising to provide a higher degree of process automation. There are only a few approaches that allow to work with indicators. They actually consider a rather coarse grained policy violation. However, these promising cost-based approaches, which allow for policy violation, are not able to adequately capture the state of obstruction and do not consider a comprehensive process structure. Regarded approaches do not start from a somehow specified obstruction, from which it would be reconstructable how the obstruction occurred in the first place. They rather assume that there is such a situation and then search for solutions without actually fully taking the obstructive situation into account. In particular, there is no representation of the problem of obstruction that captures all inputs involved. This, however, would allow to set

**Figure 2.15** Existing WSP and resilience approaches and the potential behavioral gain in handling obstructions

the frame that allows for further steps to handle the obstructive situation. Although logs constitute a further input, literature has so far not considered their use to handle an obstructive situation. In essence, the following main deficits in the detection and handling of obstructions can be observed, namely there is


**Figure 2.16** Main deficits regarding completability

#### **2.4.2 New Spheres of Action: Expanding the Behavioral Space**

How can the scope of action be widened to allow for more obstruction handling behaviour that is still compliant (see cross-hatched area)? In order to understand the general approach to obstruction handling and its requirements, the big picture, which illustrates the general effects of obstruction, is broken down to the consideration of the individual case of an obstruction again. The arrow towards the finish flag in Figure 2.16 indicates an obstruction arc. Then, the aim of the approaches of this thesis is to find a partial trace or activity sequence to complete the obstructed process execution (i.e., find the missing path to reach the finish flag). This again corresponds to what the literal meaning of the obstruction expresses. In contrast to a deadlock, which in its literal sense has no possibility of still finding a good end, an obstruction means that something is blocked, but the goal is still in sight. Therefore the goal is to clear away or bypass what is causing the obstruction to still reach the goal that has so far been blocked. Clearly, if a process obstructs in practice due to the lack of practical solutions, process participants often choose pragmatic ways beyond the identified approaches. They figure out how to work around an obstruction, for example, by making phone calls to find out why a process is blocked, or they get their business done in a way completely unrelated to the process. This is hardly observable nor even controllable form a PAIS and involves many security risks. Therefore, a security-sensitive approach to tackle obstructions needs to set the frame that allows a PAIS to be in control and aware of the obstructive situation and address the deficits of existing approaches.

#### **2.4.2.1 General Framework for Requirements**

Based on the identified deficits and against the background of Figure 2.16, three main requirements are identified for the approaches to detect and handle obstructions:


an optimal solution based on indicators, thereby taking the least risk or violation into account. Logs are not used for obstruction analysis and handling, and are useful for the indicator based view on security. Such a solution helps to better implement regulation because it allows to better consider risks as well. Here, one can imagine the help of ex ante as well as ex post approaches to steer the execution towards completion. Hence, the notion of obstructability of this work aims to handle obstructions at runtime in a way that allows to benefit from the approaches of the other phases as well. By addressing these requirements, the risk of damage by blocked process executions as well as violation of security policy shall be minimized.

In conclusion, as depicted in Figure 2.15, the goal of this thesis is to develop an approach that can detect obstructions and resolve them policy-wisely. The general approach is located between security and business goals, compliance and indicators. In the following chapters, the identified deficits will be addressed with a holistic approach that takes the design, execution and audit phase into account. Figure 2.17 illustrates problem setting and places the contributions of this work into the identified gaps. The SecANet approach (Chapter 3) addresses the lack of capturing the state of obstruction and lays the foundation for an indicator-based solution. In order to handle obstructed executions, a hybrid approach will be presented, depending on

**Figure 2.17** Contribution of work to analyze, detect and resolve obstructions

the existence of historical information. Both will be able to consider indicators such that obstructive situations will become resolvable in a security-sensitive way. The OLive-M approach (Chapter 4) will show how, based on the SecANet, model-based solutions to obstructions can be computed by using light analysis methods. The OLive-L approach (Chapter 5) foremost uses the log to find solutions to handle an obstruction. That way, this work represents a holistic approach that takes models and logs into account and is applicable at design-, run- and audit-time. Beyond the general requirements (GR) identified in this section, these approaches will address the specific requirements that apply to their execution phase (i.e., ROA, RSC, RLC).

Altogether, by analysis, detecting and handling obstructions, the goal is to improve security in business processes. Conflicts caused by security policies are supposed to be captured and resolved in a security-sensitive way and the processes are allowed to complete policy-wise, and still meet compliance. The overreaching goal is to relax the tension between too strict security controls and business goals of processes in the practical setting. By providing mechanisms that predict (or at least detect) obstructions and, based on the existing process controls and data, propose workarounds that, albeit not fully policy-compliant, allow enactment with the nearest security-sensitive match feasible, it will become possible to engineer enterprise systems with a large extent of flexibility and security.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **3 Obstruction Modeling**

The previous chapters identified the need to capture the state of obstruction as well as the fact that the inputs whose interplay may finally result in such a state are the workflow and its related policies. Although the approaches observed in Chapter 2 propose different ways to connect such authorizations and constraints with the workflow, they lack in making the obstruction state tangible in an intuitive way. Currently, it can only tediously be represented based on different inhomogeneous and limited definitions and formalizations. These approaches neither form a basis to conduct obstructability analysis nor find an adequate solution to escape an obstruction.

Based on the general framework of requirements in Chapter 2, this chapter proposes an approach that aims to address the deficits and requirements for obstructability analysis (ROA) stipulated in the previous chapter (cf. Section 2.1). For this, *one* representation that allows grasping the problem of obstruction (cf. GR-1) and facilitating its analysis (cf. GR-2) is supposed to encode the business goals and compliance requirements. In particular, such a representation should allow an adequate capturing of all inputs (cf. GR-3) of a security-aware process specification, namely the process model and the policy. On the one hand, for an obstructed case, the actual state of obstruction is supposed to be capturable in such a representation. On the other hand, it is meant to provide obstructability analysis, namely to detect obstructions in a security-aware process specification and to capture the results as well. The state of obstruction captured in the representation will then provide to search for ways how to escape from that problem during process enactment but also to be used to identify weak-spots of the policy design. A central question is how to capture the different inputs of a security-aware process expressively and, at the same time, preserve their behavior.

Because obstructions occur during the process execution, the guiding principle of this approach is to represent the obstruction state in a process-oriented way as well. Chapter 2 already introduced the manifold ways to model processes, which

J. Holderer, *Obstructions in Security-Aware Business Processes*, https://doi.org/10.1007/978-3-658-38154-7\_3

usually focus on the control flow as well as policy models (e.g., BPMN, EPC, Petri nets, RBAC, ACL). The process is, therefore, primarily anchored in the control flow. It builds the point of reference for process-oriented modeling. It can further be observed that the authorization and SoD or BoD rules manifest themselves in the activity sequences (or traces) of the process in a PAIS as well, denoting, for example, who executed which task. In this view, the overall policy can be understood in a process-oriented way too. More specifically, authorization can be regarded as a process in itself, i.e., the process of granting user access to a specific task. Further, also SoD or BoD constraints can be expressed in a process-oriented way. To follow the binding or separation of granted accesses, they reduce the options to choose who is supposed to execute which task. More precisely, these possibilities are reduced depending on the tasks already performed. Hence, in order to realize a processoriented representation, a formalism will first be identified that is able to adequately capture the control flow with respect to the identified requirements. In the next step, the policy will be "flattened" (i.e., incorporated) into the process model by using the same way of modeling as identified for the control flow. It will then be necessary to analyze if the behavior of the inputs as well as the overall system behavior is not changed.

This chapter will first explore the possibilities for the modeling of the process, which can primarily be used for the modeling of the control flow, and relate to comparable approaches beyond the WSP and resilience context. In particular, based on the identified requirements, the modeling method should allow both a comprehensive process structure (ROA-2) and an efficient analysis (ROA-3). Based on the process model representation that is considered reasonable, the policy will also be understood as process-oriented, such that it is integrable into the existing workflow. The policy will consider basic constraints (ROA-4) as well as the option for pre-assignments (ROA-1). That way, a security-aware representation that not only represents the functional and behavioral but also the organizational aspect of a security-aware process specification will emerge, named SecANet. A SecANet will also allow considering costs (ROA-6), which can be manually defined or which consider insights from the process specification or the log as well. Finally, the approach will support capturing obstructed states (ROA-7) as well as synthesizing partial plans (ROA-5) that cause obstructions. In all of this, the general intuition and feasibility behind the flattening in the SecANet approach will crystallize. The important system properties of the resulting representation will be highlighted. A SecANet decomposition will then allow reasoning to what extent the approach maintains the integrity of inputs as well as the integrity of the overall process. By introducing the so-called re-enactment, cyclic security-aware workflows can be considered by the SecANet encoding as well. Section 3.2.6 will subsume SecANet-based satisfiability and obstructability checks as SecANet soundness and show further extensions to facilitate analysis. An experimental evaluation will compare soundness checking runtimes with typical WSP-related approaches. In the course of the discussion, the computational complexity of the SecANet encoding will be examined. With the introduction of SecANet+, the SecANet approach will be generalized further. It will lay the basis to integrate additional inputs that model further behavior that affects the process. To show the extensibility of the SecANet+ approach, the integration of additional inputs that further constrain the execution of tasks, e.g., counting constraints but also resilience, will be indicated. Finally, the development of the SecANet formalism and its use as a target metamodel of security-aware process specifications creates a basis for further analysis. It will build the foundation for the model- and the log-based approach presented in Chapters 4 and 5, respectively.

#### **3.1 Ways to Model Processes**

Process models usually contain at least the control flow of a process (i.e., the entirety of valid activity sequences). Depending on the metamodel used, they may also include other aspects (data use and flow, actors, etc.). Although each metamodel has various abilities and characteristics, whose suitability depends on its application scenario, it is often possible that a formalism easily translates into other notations and formalisms [6]. UML [116, 117], BPEL [123], BPMN [118], EPCs, YAWL [105], Petri nets and Transition Systems are the most well-known and studied metamodels. Although the question about the most commonly used metamodel is hard to answer, a recent BPM survey at least states that "the OMG's modeling notation, BPMN, has become a popular, worldwide standard" [104]. To some extent, the effort of this work in capturing the policy into a single process-aware representation is comparable to approaches that provide modeling support for process-related access control models (Strembeck et. al [191], for example, list further literature for related UML, RBAC and BPMN extensions). However, the focus of this chapter is not to support such a modeling in an established metamodel. Based on a specification given in some metamodel, this chapter aims to deduce a representation that focuses on the analysis and handling of obstructability and that meets the stipulated requirements.

Notwithstanding the ideas or methods pursued or developed by the numerous approaches mentioned in Chapter 2, they all show that the prerequisite for their application is the availability of a formal model. For example, this is the case for the satisfiability analysis in which often partial orders describe the flow of process tasks, but also conformance checking. Regarding the latter, for instance, the differentiation between conforming and non-conforming process behavior demands a formal model of the control flow of the process. Up to now, the use of a formal model for the desired representation has been a rather implicit requirement. Against the background of the various metamodels already mentioned, which are often motivated by practice, it is necessary to make this requirement explicit. Such a formal model is supposed to allow the modeling of realistic processes. As identified in Chapter 2, only a few of the WSP-related approaches support comprehensive structural possibilities of processes. Because process mining aims to look at realistic (lived) processes as well, it is worthwhile to observe the metamodels used in process discovery. While, in the beginning, literature mainly based on directed graphs and state machines, there is a distinct tendency towards Petri nets. Publications from other areas of Process Mining support this trend as well [189]. Petri nets, in comparison to state-based metamodels (e.g., transition systems), are more suitable to depict concurrent behavior and causal relations between single activities within a process [55]. They are not purely textual and formal representations but also allow a graph-wise illustration. Their graphical readability is comparable to BPMN models. Petri nets provide a formal semantic and unique definitions for their structure and behavior. Different Petri net dialects allow various possibilities for analysis [2, 4, 86]. In particular, research findings on Petri net properties can be applied to business processes, such that boundedness, liveness, or reachability, for example, determine process completion. To assess the behavior of business processes, Petri net behavior can be examined by observing the language of the net, which encompasses all possible execution sequences. Because a crucial requirement of the approach of this chapter is to not only preserve the behavior of the process specification but also to consider its applicability for further analysis, it is essential to consider the influence of the chosen Petri net dialect on the existence of (efficient) analysis techniques and observability of behavior-related (in the sense of language-related) properties. Regarding the analysis of Petri nets, especially for the class of ordinary so-called Place-Transition nets (P/T nets), there is a plethora of efficient techniques [186]. In contrast, the analysis of the class of Colored Petri nets, as a typical example of high-level Petri nets, is more complex [77]. There are highlevel Petri net representations that, in some way, already allow modeling security requirements. For example, there are works on the definition of security properties on Petri nets [12, 111–113] as well as approaches for the verification of access and usage control guidelines [19, 121, 127, 139], integrity conditions [218] and requirements of information flow control [10, 11], or conflict of interest detection [217]. In contrast to ordinary nets, apart from the higher computational complexity, high-level nets do not directly reveal their behavior in their language, which limits the possibilities to reason on the required language preservation.

In essence, Petri nets are graphical, well-known, and widely used. They are the oldest and best-investigated process modeling language allowing for the modeling of concurrency in a mathematical representation. More specifically, it is the graphical nature of Petri nets, their explicit representation of the notion of state, and the existence of analysis techniques that made them eminently suitable for workflow specification [105]. In particular, their distinction between states and events (which manifest in so-called firing sequences) seems promising to depict the state of obstruction. Moreover, their graphical representation also offers the potential to visualize the security-aware process specification more intuitively. Because Petri nets appear to be suitable in many respects and meet the set requirements, they are the method of choice to model the envisaged representation. The rationale in all of this is that, on the basis of such Petri net-based representation and the plethora of analysis techniques, a way to resolve obstructions can be found as well. As far as known, the identified potential of Petri net techniques has not been applied for obstructability analysis so far. Choosing the Petri net formalism does not mean a loss of generality because it translates to other formalisms. For example, regarding formalisms often used in WSP-related approaches, it is known that a family of partial orders is needed to characterize a single Petri net [126]. Thereby, modeling the control flow with Petri nets has the advantage of compactly representing a workflow specified as potentially many partial orders (cf. Section 2.1). Further, as a rare example of WSP approaches that allow for comprehensive process structure, Basin et al. use Hoarse Process Algebra CSP. In this regard, it is always possible to transform a CSP process [213] into a Petri net (more specifically, a so-called safe Petri net). Moreover, while a transformation of informal models into formalized models is not trivial, at least for the regarded basic modeling constructs, there are transformation techniques, e.g., to transform BPMN models [79] into Petri nets1. Although Petri nets provide an intuitive and simple graphical representation, they determine a precise execution semantic.

Thus, the approach of this chapter will use Petri nets as its formal model in such a way that it is able to integrate a security-aware process specification into a single net that allows analyzing the obstructability and capturing obstructions, a so-called SecANet. Because the aim of this work is to allow for efficient computation as well as straightforward encodings and behavioral observation, the idea is to stay with ordinary nets because, as explained above, for other Petri net classes, e.g., colored Petri net, the reasoning gets harder. Therefore, all inputs will be flattened into a single P/T net. Thus, it is possible to keep the net constructions as simple as possible. Because such a P/T net can directly encode the control flow of the

<sup>1</sup> For more complex BPMN elements, there are some issues in their mapping towards a formal execution semantics such as Petri nets or other modeling languages such as the Business Process Execution Language (BPEL) [170].

process, the essential question will be how to map security policies into the net. In this regard, Chapter 2 only formalizes authorization as a mapping of the set of users to the respective set of workflow tasks so far. Moreover, it captures SoD and BoD constraints with the help of different binary relations from the set of users on the respective tasks, for example, entailment constraints. Thus, also straightforward user-task assignments that can be represented by ACLs will be chosen, instead of the more complex representation of RBAC (which, in turn, may also be decomposed to a direct user-task assignment).

The following section is going to formally describe Petri nets, in particular, ordinary Petri nets (or P/T nets), and related concepts. P/T nets build the foundation for the definition of different net properties and net subclasses such as workflow nets (WF-nets), which allow modeling workflows with a precise task execution semantic. The properties of Petri nets such as boundedness, safeness, liveness or deadlockfreeness, will be of interest because they affect, for example, the computational complexity, the interpretability of the state of the net as well as language-related reasoning. After the definitions related to Petri nets, users, user-task authorization as well as SoD and BoD constraints will be defined. That way, the basis will be laid to formally grasp obstructability in workflows.

#### **3.1.1 Petri Nets: The Method**

Petri nets represent a graphical and mathematical modeling tool that can be applied to many systems. As described above, they are very well suited for the description and investigation of information processing systems that are characterized as concurrent, asynchronous, parallel, or non-deterministic. Their graphical nature allows for visual communication similar to flowcharts, block diagrams, and networks. Additionally, within these nets, tokens are used to simulate the dynamic and simultaneous activities of systems. That way, a Petri net can encode certain properties of the system it models. There are structural and behavioral properties that relate to the net structure, or the token-related dynamic behavior, respectively. As a mathematical tool, it is possible to set up state equations, algebraic equations, and other mathematical models for system behavior. Petri nets are therefore suitable for both practical and theoretical use [155]. The following definitions related to Petri nets and to properties that will be of relevance in this thesis will mainly base on the works of Murata et al. [155], Desel, Esparza (e.g., free-choice net [73]), and van der Aalst et al. (e.g., WF-nets [3]).

#### **3.1.1.1 Petri Net**

A Petri net is a bipartite graph consisting of places graphically represented as a circle and transitions depicted usually as squares, rectangles, or vertical lines. Only two distinct nodes can be related to each other via directed arcs or edges (i.e., an arc connects a place with a transition or vice versa). The resulting net structure is static, but tokens controlled by the firing rule can flow through the network. The distribution of the tokens over the places determine the state of a Petri net and represents its marking [3].

**Figure 3.1** Petri net of the Determine Market Value (DMV) process

Figure 3.1 shows an example of a Petri net that models the process of two sequentially ordered tasks *t*<sup>1</sup> and *t*<sup>2</sup> wherein the leftmost place contains one token2. The written formal notation of this example will be given after the definition for Petri nets.

**Definition 3.1 (Petri Net and Marking).** *A Petri net is a 4-tuple N* = -*P*, *T* , *F*, *m*0 *, where P is the set of places, T is the set of transitions, satisfying P* ∩ *T* = ∅ and *F* : (*P* × *T* ) ∪ (*T* × *P*) → {0, 1} *is the flow relation, and m*<sup>0</sup> *is the initial marking.*

*A marking (state) is an assignment of a non-negative integer to each place. If a non-negative integer k is assigned to place p by a marking, it can be said that p is marked with k tokens. For this, a marking is denoted as a* |*P*| *vector* **<sup>m</sup>** <sup>∈</sup> <sup>N</sup>|*P*<sup>|</sup> *, where the component p of the vector is a natural number. Then, the p-th component of* **m***, denoted by m*(*p*)*, is the number of tokens in place p. To allow for better readability, markings can also be denoted as sets or multi-sets. Because a linear order is assumed for the set of places P* = {*p*1,..., *p*|*P*|}*, the characteristic vector (or indicator/incidence vector) can be used to link the vector notation with the (multi-)set notation. For a set m* ⊆ *P (or a multi-set or bag m* ∈ *B*(*P*) over *P), the characteristic vector of m with respect to P can be denoted as* χ (*m*) = *x*1,..., *x*|*p*|*, where xi* = 1

<sup>2</sup> For the sake of clarity, the added tokens, the three places *p*1, *p*<sup>2</sup> and *p*<sup>3</sup> (from left to right), are not labeled with their names here.

*if and only if (shortened as iff) pi* ∈ *m* (or *xi is the multiplicity of pi in the multi-set m) and* 0 *otherwise, for* 1 ≤ *i* ≤ |*P*|.*In this work, markings will explicitly be written as (place) vectors* **m** *if required. Normally, however, the notation used is evident from the given specific context.*

Based on Definition 3.1, the net P/T net *N* depicted in Figure 3.1 can be denoted as *P* = {*p*1, *p*2, *p*3}, *T* = {*t*1, *t*2}, *F* = {*p*1, *t*1,*t*1, *p*2,*p*2, *t*2,*t*2, *p*3} and the marking *m*<sup>0</sup> = -1, 0, 0. The visualized marking defines that a single token (small solid black circle) is assigned to place *p*0. This is the standard visualization of markings that is equivalent to their formal definition. To illustrate the different marking notations, suppose *p*<sup>1</sup> is marked with 1, *p*<sup>3</sup> with 3 and all other places with 0 tokens. This marking *m* can be denoted as *m*(*p*1) = 1, *m*(*p*2) = 0 and *m*(*p*3) = 3, or as the multi-set {*p*1, *<sup>p</sup>*<sup>3</sup> <sup>3</sup>}, or as the characteristic vector χ ({*p*1, *<sup>p</sup>*<sup>3</sup> <sup>3</sup>}) that, in turn, encodes the vector notation of the marking -1, 0, 3.

The set of places and transitions build the nodes of a net. The definition of flow relations above does not allow so-called arc weights > 1. A Petri net is said to be ordinary (or plain) if all of its arc weights are 1's, i.e., an arc only allows to produce or consume exactly 1 token [155]. As mentioned before, all Petri nets considered in this thesis are ordinary P/T nets. The set-based definition of the flow-relation further implies that there may not be multiple arcs between the same pair of nodes (which prevents the possibility to model arc weights > 1 with multiple arcs). Based on the given net structure, paths between the nodes are connected by a sequence of arcs.

**Definition 3.2 (Paths and Cycles).** *A path is a sequence of nodes u*1,..., *ur such that* ∀*i*, 1 ≤ *i* < *r* : *F*(*ui*, *ui*+1) > 0*, i.e., ui*+<sup>1</sup> *is an output of node ui . A path is called simple if no node appears more than once on it. A simple path is called a cycle if all nodes along the path differ, except for the initial and the final node.*

**Definition 3.3 (Strong Connectedness).** *A Petri net is strongly connected iff, for every pair of nodes (i.e., places and transitions) x and y, there is a path leading from x to y.*

A further structural characterization related to paths is given by the notion of socalled PT- or TP-handles, whose existence indicates a rather "bad" structure.

**Definition 3.4 (PT-handle and TP-handle [90]).** *A place-transition pair* (*p*, *t*) ∈ *P* × *T is called a PT-handle iff there are two simple paths from p to t sharing only the two nodes p and t ; a transition-place pair* (*t*, *p*) ∈ *T* × *P is called a TP-handle iff there are two simple paths from t to p sharing only nodes p and t.*

Hence, Figure 3.1 is not strongly connected because there is for example no directed path for the pair (*p*3, *p*1) that leads from *p*<sup>3</sup> to *p*1. However, it does not contain PT- nor TP-handles. The notion of pre- and post-set is essential to describe net properties, in particular, regarding the net structure.

**Definition 3.5 (Pre-set, Post-set).** *Given a node x* ∈ *P* ∪ *T* , *its pre-set* {*y*|*y*, *x* ∈ *F*} *and post-set* {*y*|*x*, *y* ∈ *F*} *are denoted by* • *x and x*• *, respectively.*

For instance, in Figure 3.1 the pre- and post-sets of *t* − 1 and *p*<sup>1</sup> can be denoted as • *t*<sup>1</sup> = {*p*1},*t*• <sup>1</sup> = {*p*2}, •*p*<sup>1</sup> = ∅ and *p*• <sup>1</sup> = {*t*1}.

So far, the definitions have mainly focused on the properties given by the basic net structure. As indicated before, besides the net structure, a Petri net model of a dynamic system also consists of a marking. The system dynamics or behavior is given by the evolution rules for the marking [186].

The following definitions are token-related and therefore allow the consideration of properties related to the behavior of the net. The distribution of tokens results from a marking (cf. Definition 3.1). A transition can "fire" when all its input places are marked. This Petri net terminology of "firing" a transition represents the execution of a task (which, in turn, stands for the execution of an activity). Firing a transition generates a new marking. Thereby, each input place of the transition loses one token, and each output place of the transition receives one token. Thus, the execution semantics of a Petri net can be grasped as a token flow game that follows this firing rule. That way, the token flow determines the actual system behavior, which is why, as soon as Petri nets are marked, literature often uses the term "system" in different variations.

**Figure 3.2** DMV Petri net with initial marking

**Definition 3.6 (Enabledness and Firing Rule).** *A transition t is enabled in a marking m when all places in* • *t are marked, which can be denoted by* (*N*, *m*)[*t iff* **m** ≥ χ (• *t*) *(vector notation) or m* ≥• *t (multi-set notation), respectively*3*. When a transition t is enabled, it can fire by removing (or consuming) a token from each place in* • *t and putting (or producing) a token to each place in t*•*.*

For instance, based on the given marking in Figure 3.2, transition *t*<sup>1</sup> is enabled (highlighted with red) because all places in • *t*<sup>1</sup> are marked. Firing *t*<sup>1</sup> then consumes a token from each place in • *t*<sup>1</sup> and produces a token in each place *t*•, which results in the marking *m*<sup>1</sup> = -0, 1, 0 depicted in Figure 3.3.

A transition without any input place is called a "source transition", and one without any output place is called a "sink transition". Based on Definition 3.6, a source transition is unconditionally enabled, and the firing of a sink transition consumes tokens, but does not produce any. A pair of a place *p* and a transition *t* is called a self-loop if *p* is both an input and output place of *t* (e.g, to model a "do-while-loop"). A Petri net is said to be pure if it has no self-loops. Based on the firing rule the set of reachable markings of the Petri net, also called its state space, can be determined.

<sup>3</sup> Because multi-sets are essentially vectors with natural numbers as components (cf. Definition 3.1), they can be used for calculation component by component and to compare them in the same way as it is usual for Petri net vector markings.

**Definition 3.7 (Reachability and Feasible Sequences).** *Given a Petri net N, a marking m is reachable from m if there is a sequence of firings t*1*t*<sup>2</sup> ... *tn that transforms m into m , denoted by m*[*t*1*t*<sup>2</sup> ... *tnm or m* ∈ *R*(*N*, *m*)*. A sequence of transitions t*1*t*<sup>2</sup> ... *tn is a feasible sequence if it is fireable from m*<sup>0</sup> *. The set of reachable markings from m*<sup>0</sup> *is denoted by* [*m*0*.*

For instance, based on the marking *m*<sup>0</sup> = -1, 0, 0 depicted in the Petri net of Figure 3.1, the marking *m*<sup>1</sup> = -0, 1, 0 shown in Figure 3.3 is reachable through the feasible sequence *t*1, while, for example, the marking *m* = -0, 1, 1 is not reachable. Hence, the reachability of the marking in Figure 3.3 can be denoted as *m*0[*t*1*m*1.

The set of reachable markings represents the set of states of the system. The transitions between the markings represent transitions between the states. Hence, to capture the behavior of a Petri net, a transition system can be obtained. It contains a set of possible states and a set of transitions that stand for the potential changes of the systems state. That way, transition systems represent automatons that describe the behavior of a system of processes [18]. After the succeeding definition of transition systems, the reachability graph (or marking graph) can be defined.

**Figure 3.3** DMV Petri net with new marking after firing *t*<sup>1</sup>

**Definition 3.8 (Transition System).** *A Transition System (TS) is a 4-tuple* (*S*, *E*, *A*,*sin*) *where S is a set of states, E is a set of events where S* ∩ *E* = ∅*, A* ⊆ *S* × *E* × *S is the set of arcs (or transitions), which connect states, and sin* ∈ *S is the initial state. The transitions are denoted by* (*s*, *e*,*s* ) *or s <sup>e</sup>* −→ *s . <sup>S</sup>*<sup>0</sup> := {*<sup>s</sup>* <sup>∈</sup> *<sup>S</sup>* <sup>|</sup> - (*s*, *e*,*s* ) ∈ *A*} *denotes sinks within the TS, i.e., states without outgoing arcs.*

A TS is called finite when S and E are finite. This thesis only deals with finite transition systems. A state *s* is reachable from a state *s* if there is a sequence of events σ = -(*s*, *e*1,*s*1)...(*sk* , *ek* ,*s* ). Reachability can be denoted with *<sup>s</sup>* <sup>∗</sup> −→ *s* or, specifically, *<sup>s</sup>* <sup>σ</sup> −→ *s* . Based on this, the reachability graph can be defined as follows.

**Definition 3.9 (Reachability Graph).** *For a Petri net N* = (*P*, *T* , *F*, *m*0)*, the reachability graph RG*(*N*) *represents a TS whose states correspond to the set of reachable markings* [*m*0 *and whose events correspond to transitions. There is an arc* (*m*, *t*, *m* ) iff *<sup>m</sup> <sup>t</sup>* −→ *m . m*<sup>0</sup> *is the initial state.*

The boundedness of a Petri net means that, within all reachable markings, there is an upper bound for the number of tokens contained in places. Thus, it is a consequence of the finiteness of its reachability graph. A 1-bounded Petri net is called "safe".

**Definition 3.10 (Boundedness and Safeness).** *A Petri net is bounded iff for every reachable state and every place p the number of tokens in p is bounded, i.e., there is an integer k such that the number of tokens in any place cannot exceed k. More specifically, a Petri net is k-bounded if no marking in* [*m*0 *assigns more than k tokens to any place of the net. A net is bounded if it is k-bounded for some k such that no place holds more than k-tokens, i.e.,* ∀*p* ∈ *P and* ∀*m* ∈ [*N*, *m*0 : *m*[*p*] < *k*. *A Petri net is safe if the numbers of tokens in each place cannot exceed one, i.e., it is 1-bounded.*

Although the terms of liveness and safety that are introduced in this section are reminiscent of the two classes of security properties considered in Chapter 2, it is important to note that safety and liveness security properties are not equivalent to their counterparts in Petri net theory. However, they can be used to describe somewhat similar properties [132].

**Definition 3.11 (Liveness).** *A PN is live iff every transition can be infinitely enabled through some feasible sequence of firings from any marking in* [*m*0*. Hence, for no matter which marking has been reached from m*0*, then for each transition t of the model, there must be a sequence of firing such that the resulted marking enables t, i.e.,* ∀*m* ∈ [*N*, *m*0*,* ∃ *m* ∈ [*N*, *m such that* (*N*, *m*)[*t. Further, a transition is "simply live" if it can fire at least once. A Petri net is "simply live" if all of its transitions are simply live.*

Historically, the concept of a safe or n-safe (or n-bound) Petri net as well as liveness and related variants have been in use since the 1970s. At the beginning of the 1980s, temporal logic then distinguished between safety properties and liveness properties (i.e.,"something bad" or "something good" happens, respectively). As elaborated in Chapter 2, a sensible description of the requirements of a system always includes properties of both types [172]. This analogy also applies to Petri nets because the properties of liveness and n-safeness can be subsumed under the notion of wellformedness.

**Definition 3.12 (Well-Formedness).** *A Petri net N is well-formed iff there is a state m for the net such that* (*N*, *m*) *is live and bounded.*

**Definition 3.13 (Deadlock-Freeness).** *A Petri net N is said to be deadlockfree if at least one transition is enabled at each marking m derived from the initial marking m*0*.*

**Definition 3.14 (Reversibility).** *A net is reversible if the initial marking m*<sup>0</sup> *is reachable from every marking of* [*m*0*. This means that the system can get initial settings after it is executed.*

It should be noted that liveness, boundedness, and reversibility are independent of each other. Because the notion of obstruction can be compared to a deadlock situation, the notion of siphons and traps will be introduced.

**Definition 3.15 (Siphon).** *A siphon (or also named deadlock) is a set of places such that every transition that outputs to one of the places in the siphon also inputs from one of these places. Formally, a non-empty subset of places D of a net is a siphon if* • *D* ⊆ *D*•*. This means that if a siphon is blank (i.e., does not contain any tokens), it will remain blank for every possible firing sequence. Hence, if a marking m* ∈ [*N*, *m*0 *is in a deadlock state, then* ∀*d* ∈ *D* : *m*[*d*] = 0, i.e., *D is an unmarked set of places. In this case, no* *transition can place a token in the siphon because there is no token in the siphon to enable a transition that outputs to a place in the siphon.*

Because every transition that has an input place in a "blank" siphon is in a deadlock and will have no chance of firing, a siphon is "bad" for liveness. Such a deadlock, in the sense of a Petri Net, is a deadlock in the usual sense only if it is blank. Therefore, literature also refers to the wording "potential deadlock" for the siphons defined above [161].

**Definition 3.16 (Trap).** *A trap is a set of places such that every transition that inputs from one of these places also outputs to one of these places. Formally, a non-empty subset of places D of a net is a trap if D*• ⊆ • *D. Hence, once a trap is marked (i.e., does contain at least one token), it will always be marked, no matter what firing sequences take place. Once a token is in any of the places of a trap, there will always be a token in one of the places of the trap. Hence, if marking m* ∈ [*N*, *m*0 *is in a trap state then* ∃*d* ∈ *D* : *m*[*d*] = 1*, i.e., D contains at least one marked place. In other words, the firing of transitions may move the token between places but cannot remove all tokens from a trap.*

For instance, the net in Figure 3.1 contains the siphon *D* = {*P*0} because • *D* = ∅ and *D*• = {*t*1}, i.e., • *D* ⊆ *D*• and the trap *D* = {*P*2} because *D*• = ∅ and • *D* = {*t*2}, i.e., *D*• ⊆ • *D*. A more detailed explanation will be given in the course of the example SecANet in Section 3.2.

Traps and deadlocks are not exclusive. For instance, every strongly connected Petri Net is both a trap and a siphon. An essential connection between traps and siphons is that if a deadlock contains a marked trap, it will never become blank, such that this siphon is no threat to liveness anymore. This property is also known as the siphon/trap- or trap/co-trap-property [51].

#### **3.1.1.2 Basic Modeling Examples**

Several fundamental situations may occur in the dynamic behavior of Petri net systems. In particular, a strong feature of Petri net models is that notions concerning concurrent systems can be formulated in a very natural way. Based on the previous definitions, basic modeling possibilities that illustrate how a Petri net can be used and composed to model the required sequential, parallel, conditional (or exclusive) and looping behavior (cf. ROA-2) will be provided. For this, three fundamental relationships that may hold between the occurrence of two events, i.e., the firing of transitions *t*<sup>1</sup> and *t*<sup>2</sup> (which may model tasks, or activities), will be regarded: causality, concurrency, and choice [155].

**Causality:** Causality means that the occurrence of an event conditions the occurrence of another one. This results in a sequential order. Figure 3.1 illustrates an example of such a causal relationship. Here, *t*<sup>1</sup> needs to occur to enable *t*2, or, in other words, firing *t*<sup>1</sup> is the cause that enables *t*2.

Besides modeling causal relationships, the possibilities of a Petri net modeling concurrent systems are distinctively interesting for parallelism and nondeterminism. The non-deterministic and nonsimultaneous firing of transitions is reflected in the following two ways [161]:

**Concurrency:** When two enabled transitions do not affect one another in any way (i.e., they are causally independent), and a transition may fire before or after or in parallel with the other, it is called concurrency. There is no need to synchronize the events unless it is required by the underlying system that is being modeled. When synchronization is needed, it is easy to model this as well. The Petri net shown in Figure 3.4 [155] illustrates how this can be expressed. The parallel or concurrent activities are represented by transitions *t*<sup>1</sup> and *t*2. They are both enabled after the firing of the transition *Parallel Begin*. After the firing of both parallel transitions, the transition *Parallel End* can fire. Moreover, the path from *Parallel End* to *Parallel Begin* models a loop.

**Figure 3.4** Parallel activities in a Petri net

**Figure 3.5** Conflict, choice, or decision Petri net structure

**Choice:** The other situation, in which simultaneousness is more difficult to tackle, can be handled by defining events that occur non-simultaneously. This structure of the place *p*, having two (or more) output transitions*t*<sup>1</sup> and *t*<sup>2</sup> as shown in Figure 3.5, is referred to as a conflict, decision, or choice, depending on its applications. Both activities are enabled but only one of them can be executed. In other words, only one transition can fire because, by firing, it removes the token in the shared input and disables the other transition. Hence, a choice relationship can be used to model decision nodes for exclusive paths or conditional gateways in a process model. It is a structure exhibiting non-determinism [155], in a sense that the selection which single transition to fire out of a set of enabled transitions may be determined in the modeled system, but not in the model simply because the model does not contain the complete information about the system. For instance, in the DMV example, the decision if the computation of the market value is correct cannot be solely assessed by the information provided by the model. In practice, at least the expertise of the case officer and further context information on the collateral under consideration and its computed market value would be required.

In summary, two events are causal if *t*<sup>1</sup> causes*t*2, they are in conflict if either *t*<sup>1</sup> or *t*<sup>2</sup> can occur but not both, and they are concurrent if both events can occur in any order without conflicts. These examples illustrate that Petri nets can comprehensively model the required structures and that they constitute a basic construction kit for Petri net modeling. In the combination of these elements, further, but still rather basic, situations can be observed. When conflict and concurrency are mixed, it is called confusion. There are two types of confusion. Figure 3.6 shows a symmetric confusion because two events *t*<sup>1</sup> and *t*<sup>2</sup> are concurrent while each of *t*<sup>1</sup> and *t*<sup>2</sup> is in conflict with event *t*3. Figure 3.7 shows an asymmetric confusion, where *t*<sup>1</sup> is concurrent with *t*<sup>2</sup> but will be in conflict with *t*<sup>3</sup> if *t*<sup>2</sup> fires first. These elementary relationships between activities will be important in the subsequent identification of Petri net subclasses as well because they provide a means to assess their modeling capabilities.

**Figure 3.6** Symmetric confusion

**Figure 3.7** Asymmetric confusion

#### **3.1.2 Petri Net Subclasses**

The introduction above on ordinary Petri nets (i.e., P/T nets) allows a more thorough elaboration of the mentioned aspects regarding the suitability of high-level Petri nets. The underlying question is whether ordinary nets are sufficient to cover all relevant inputs or whether extended nets may address the requirements of the envisaged representation in a better way.

To start with, the simpler the structure of a Petri net is, the simpler the formal description of the behavior of individual transitions and also the corresponding analysis procedures become. On the other hand, simplifying the net also lowers the level of detail of the model and counteracts the modeling efficiency and the convenience of modifications and the extension of Petri nets. Regarding the latter, besides timed Petri nets [168] or stochastic nets [151], the introduction of individual objects as tokens particularly increases the descriptive power of nets and allows for small but efficient as well as practical modeling of systems. Such aforementioned high-level nets subsume predicate/transition nets [95], colored Petri nets (CPNs)[120], or nets with individual tokens [171] (e.g., relation nets) [155]. That way, Petri nets can be extended, for example, with resources, data, users, or also time-related information, which results in different Petri nets dialects. Besides the fact that different token colors can be used to represent data-aspects, e.g., modeling data items or the information flow [190], they also allow modeling access control policies by modeling users [139, 191], which is particularly interesting for the intended modeling. However, such data-oriented nets not only require more complex analysis techniques [77] but also complicate behavioral observation. When, for example, token colors represent users, the transition execution sequences may not directly reveal decisions related to user accesses. In this case, the behavior of the system is not explicitly expressed in the language of the net. Although methods to transform CPNs to ordinary nets can overcome these issues, such unfoldings represent a separate step that would have to precede the desired representation [77]. Folding into (or unfolding from) a CPN, however, requires knowledge of the still unknown desired representation. Instead, the language should reflect user accesses for now, which means that transitions need to be used not only for task or activity modeling but for policy modeling as well.

Hence, in contrast to extended Petri nets, using P/T nets for the intended modeling implies that both the data reasoning stays gentle and policy-related behavioral properties are reflected in the language of the net as well. Nevertheless, in the wake of the requirement to allow for efficient solutions, it is not necessarily sufficient to only consider the class of P/T nets for this but it is necessary to also examine the implications of specific subclasses and properties on later analyses. Therefore, the subsequent section will not look at high-level abstractions and extensions beyond P/T nets. Instead, it will scrutinize the class of ordinary Petri nets more thoroughly. By imposing restrictions on these Petri nets, in particular on the net structure, the following different Petri net subclasses can be obtained [32, 51, 101].

#### **3.1.2.1 Place- and Transition-Related Systems**

**Definition 3.17 ( State Machine or S-System**4**).** *A State Machine (SM) is a Petri net such that each transition has exactly one input place and one output place.*

<sup>4</sup> S stands for the word "Stellen" ("places" in English) whose use goes back to Petri's dissertation, written in German.

Petri net state machines can describe all finite automaton. The characteristic nodes in SMs are the places. Each transition allows the tokens to flow from one place to another, but a token in a particular place may enable multiple transitions, which represents a conflict (as depicted in Figure 3.5).

**Definition 3.18 (Marked Graph or T-System).** *A Marked Graph (MG) is a Petri net such that each place has exactly one input transition and one output transition.*

The characteristic nodes in a marked graph are the transitions. Each place receives tokens from one transition and loses tokens to another, but a single transition may have multiple input and output places. Marked graphs allow synchronization, as depicted in Figure 3.4. That way, tokens in multiple places are simultaneously lost due to the firing of a single output transition and gained by firing a single input transition.

Some nets, for example, a closed-loop of transitions and places (which does not have any conflict or synchronization), are both an MG and an SM. However, in general, the Petri net subclass of state machines allows the representation of decisions but does not allow for synchronization (concurrency is only possible if more than one token is distributed over the net). On the other hand, marked graphs allow the representation of concurrency but not of decisions or conflicts. Hence, both do not allow the comprehensive modeling capabilities that are required for the approach.

#### **3.1.2.2 Choice-Related Nets**

A restricted Petri net subclass that allows for non-trivial behaviors, in particular conflicts and synchronizations, builds the class of free-choice Petri nets, which can be seen as a State Machine enriched with a Marked Graph. Free-choice nets have the behavioral feature that if two transitions share an input place, and if that place is marked, both transitions are enabled, or there is no marking that enables one transition and disables the other one. For instance, the choice construct depicted in Figure 3.5 is an example of free-choice.

**Definition 3.19 (Free-Choice Nets).** *A Free-Choice (FC) net is a Petri net such that every arc* < *p*, *t* > *from a place p to a transition t is either a unique outgoing arc (t is the only output transition of p (no choice)) or a unique incoming arc to a transition ( p is the only input place of t (no synchronization)). Hence, for all pairs of places p*1, *p*<sup>2</sup> ∈ *P, if p*• <sup>1</sup> ∩ *p*• <sup>2</sup> = φ then |*p*• 1|=|*p*• <sup>2</sup>| = 1.

In other words, if any output transition of a place *p* is enabled, then all output transitions of that place *p* are enabled. Hence, in this sense, it is possible to freely choose which of the enabled transitions is supposed to fire. Each of the three nets in Figure 3.8 represents a self-contained sufficient description of free-choice nets. To extend the class of nets while retaining this basic property of a free-choice between conflicting transitions, the majority of papers on FC nets use a slightly weaker definition. A system of such a so-called extended free-choice net can be simulated by an FC system.

**Figure 3.8** Three manifestation of the free-choice property

**Definition 3.20 (Extended Free-Choice Net).** *An Extended Free-Choice (EFC) net, is a Petri net such that for all pairs of places p*1,*p*<sup>2</sup> ∈ *P*, if *p*• <sup>1</sup> ∩ *p*• <sup>2</sup> = ∅*, then p*• <sup>1</sup> = *p*• 2*.*

For example, the EFC net in Figure 3.9(a) can be simulated by the FC net in Figure 3.9(b). (Extended) Free-choice nets are essential in the theory of net systems, in particular in the structural theory of Petri nets. Their structural and behavioral prop-

**Figure 3.9** (Extended) free-choice

erties are strongly interrelated, i.e., the behavior of a marked net can be connected to the structure of the underlying unmarked net [32]. For example, in the light of the state space explosion problem in behavioral Petri net analysis, such structural methods are more appropriate to deduct if a specific marking can be reached. Even in bounded nets, the state space can be exponential on the size of the net. In FC nets, liveness and well-formedness, which subsumes boundedness, can be linked to siphons and marked traps (Commoner's Theorem [51]) as well as to the rank of the incidence matrix of the net (Rank Theorem [73]). In the course of this work, FC nets are particularly interesting because, firstly, they are able to model the stipulated non-trivial control flow requirements (ROA-2) and, secondly, there are still powerful methods for their analysis and synthesis (ROA-3). While, for example, reachability is EXPSPACE hard for arbitrary Petri nets [146] and still NP-complete [88] for live and safe FC nets, it is efficiently solvable for the class of FC live, safe and reversible Petri nets [75]. Furthermore, the problem of deciding whether an FC Petri net is live and bounded is solvable in *O*(*n* ∗ *m*) time, whereby *n* is the number of places and *m* the number of transitions. Many of the analysis problems of live and bounded FC Petri nets have, in turn, been shown to have polynomial time complexity [88].

When decisions are not made "freely" but are influenced by previously executed activities, so-called asymmetric choice (AC) nets may describe this. The combination of choice and synchronization (which has been identified before as "confusion") is also termed Non-Free-Choice (NFC).

**Definition 3.21 (An Asymmetric Choice Net).** *An Asymmetric Choice (AC) net (also known as a simple net) is an ordinary Petri net such that for all pairs of places p*1,*p*<sup>2</sup> ∈ *P*, if *p*• <sup>1</sup> ∩ *p*• <sup>2</sup> = ∅*, then p*• <sup>1</sup> ⊆ *p*• <sup>2</sup> or *p*• <sup>2</sup> ⊆ *p*• 1

ACs [32] allow asymmetric confusion (see Figure 3.6 for an asymmetric combination of choice and concurrency) but disallow symmetric confusion (cf. Figure 3.7). The post-sets of any two places may be disjoint or identical (as in free-choice), or one post-set may be contained in the other. Hence, asymmetric choice nets represent an extension of free-choice nets where the theorems that are important in FC only hold partially [73, 122]. The study of the property analysis complexity of ACs found, for example, that it is co-NP-hard for the analysis of liveness and boundedness [136].

#### **3.1.2.3 Workflow Net**

As a further subclass within the class of ordinary nets, the so-called workflow nets (WF-nets [4]) can be used to represent processes in process-aware information systems with Petri nets. Therefore, the techniques and methods of this thesis assume that the control flow of the process is specified with such a type of net. A WF-net satisfies two requirements: Firstly, a WF-net is a Petri net that has one input place *i* (denoting the initial state of the system) with no incoming arcs and an output place *o* (denoting the final state of the system) with no outgoing arcs. A token in *i* corresponds to a case that needs to be handled and a token in *o* corresponds to a handled or completed case. The transitions in a WF-net represent tasks and the places represent conditions. Both should contribute to the processing of a case, such that in a WF-net, there are no dangling tasks or conditions. Therefore, every transition *t*, or place *p*, respectively, should be located on a path from place *i* to place *o*. The later requirement corresponds to strong connectedness (cf. Definition 3.3). Its examination requires that *o* is connected to *i* via an additional transition *t*∗ [4]. These two structural properties are termed "WF-structuredness".

**Definition 3.22 (WF-Net).** *A Petri net N* = -*<sup>P</sup>*, *<sup>T</sup>* <sup>5</sup>, *<sup>F</sup>*, *<sup>m</sup>*0 *is a W F -net (Workflow net) iff* [4]:


<sup>5</sup> The transitions in a WF-net typically represent tasks, which is why, for syntactic simplicity and legibility, the notation *t* is overloaded for both transitions and tasks (or *T* for the respective sets).

The example of a Petri net in Figure 3.1 already represents a WF-net. It can be regarded as the mapping of the BPMN workflow model of the "determine market value" process into a WF-net representation, in which *t*<sup>1</sup> represents the "determine market value" task, and *t*<sup>2</sup> stands for the "control computation" task. Moreover, there is a source place, and a sink place whereas all other nodes are on a path between them.

In order to be able to elaborate on possible task execution sequences of a given workflow net, systems nets are introduced. This will particularly be relevant to grasp complete but also incomplete execution sequences.

**Definition 3.23 (System Net, Full and Terminal Firing Sequences).** *A System Net (SN) defines a set of sequences, each one starting from the initial marking and ending in the final marking. A SN is a tuple SN* = (*N*, *mstart*, *mend* )*, where N is a WF-net and the two last elements define the initial and final marking of the net, respectively. The set SN* = {<sup>σ</sup> <sup>|</sup> (*N*, *mstart*)[σ(*N*, *mend* )} *denotes all the full firing sequences of SN.*

*In this work, the notion of an end marking or final state differs from a terminal state. Final states, such as mend , are defined. Terminal states represent the states (markings) that do not allow the firing of any further transition. Accordingly, the set T<sup>N</sup>* = {σ | (*N*, *m*0)[σ(*N*, *m* ) <sup>∧</sup> *<sup>m</sup>* ∈ [*m*0 ∧ *t* ∈ *T* : *m* [*t*} *denotes all the terminal firing sequences of the net N with its initial marking m*0*. Accordingly, based on an initial marking m*0*, the set of terminal markings* {*m*|*<sup>m</sup>* ∈ [*m*0 ∧ *t* ∈ *T* : *m*[*t*} *is denoted by* [*m*0*<sup>T</sup> .*

For example, for the WF-net in Figure 3.1, the set of full firing sequences of the system net *SN* <sup>=</sup> (*N*,{*p*0},{*p*2}) is *SN* = {*t*1, *t*2} = *T<sup>N</sup>* . That way, it is possible to link reachability with completability because a non-reachable end marking may indicate an unsatisfiable workflow. The fact that the firing sequence of the example net encodes safety properties (e.g., *t*<sup>1</sup> occurs before *t*2) and liveness properties (e.g., eventually *t*<sup>2</sup> occurs) underlines that each property of an initially marked Petri net can be composed of its safety and liveness properties [13].

#### **3.1.2.4 Workflow Soundness**

The requirements stated for a WF-net in Definition 3.22 are minimal requirements [4]. Even if these requirements are satisfied, it is still possible to determine a workflow process definition with potential deadlocks. Hence, WF-nets must meet some properties to avoid unexpected results subsumed in the subsequent soundness criteria [7]. To a large extent, these assumptions often refer in some way to the absence or existence of deadlocks, which underlines, in turn, the effort to ensure the completion of the workflow. Based on the typical properties of a P/T net and WFstructuredness, a WF-net is sound if and only if the following three requirements are satisfied:

**Definition 3.24 (Soundness of a Workflow Net).** *A W F -net with input place i and output place o is sound if the following conditions are met:*


To analyze these criteria, the structural characteristics of the regarded nets are again decisive. While, for a complex WF-net, it may be intractable to decide on its soundness, if the structure of a WF-net is, for example, free-choice, the soundness problem is solvable in polynomial time [7]. In contrast, the soundness problem in asymmetric choice WF-nets has been proven to be Co-NP-Hard [136].

**Block-Structure:** As a further way to facilitate soundness analysis, another approach that aims to obtain a structural characterization of "good" workflows is to assume block-structured models [7]. Although, in general, there are different definitions in this respect [105, 140, 212], the property of such block-structured models usually refers to the need for synchronization of splits and joins of the paths in the control flow. These blocks are entered as well as left at a single point. That way, there is only a single branch going in and out, before and after the block. Thus, these blocks are also called single-entry single-exit (SESE [40, 110]) regions. Subsequently, the fundamental types of such blocks in workflows, which are also known as basic workflow patterns [6], will be illustrated (building on the concise summary of the patterns from Carmona et al. [40]). Thereby, their similarity to the previously introduced basic Petri net examples will become evident.

• **Sequential Pattern:** The sequence pattern forms a strong relationship between the connected tasks (see Figure 3.10). It restricts the process in such a way that activities are only executed in the sequential order specified for the respective tasks.

**Figure 3.10** Sequential pattern

**Figure 3.11** Exclusive pattern


possible to choose to go back to an earlier point in the process to indicate that one wishes to repeat the activities represented by the respective tasks starting from that point. That way, the control flow forms a loop that can have as many iterations as desired. Each time the same decision point is reached, it can be decided whether to go back and do another iteration or to leave the loop and continue the process. It is important to note that such a loop or cycle begins with an exclusive join operation that merges the current control flow with a branch that may only be taken in the future. Hence, such a loop has a single-entry and a single-exit point as well.

**Figure 3.12** Parallel pattern

**Figure 3.13** Loop pattern

Based on these blocks, it is possible to build more complex process models by nesting these workflow patterns. Despite the specific pattern, it can be observed that splits initiate branching and thus set paths in either a parallel or exclusive relationship to each other. Joins reunite these paths, i.e., they synchronize them. Hence, two parallel flows initiated by a parallel split must not be joined by an exclusive join. Equivalently, two alternative flows created via an exclusive split, must not be synchronized by a parallel join. Instead, a parallel join should complement a parallel split, and an exclusive join should complement an exclusive split [7]. If a model consists only of such blocks, or such SESE regions, respectively, the model is called block-structured (or well-structured). "Unstructured models" describe models that do not have this property. To define this characteristic of balancing equivalent splits and joins for WF-net models, the existence of PT- and TP-handles will be examined.

**Definition 3.25 (Well-Handled).** *A Petri net PN is well-handled iff it has neither PT-handles nor TP-handles.*

A Petri net that is well-handled has several desirable properties, for example, strongly connectedness and well-formedness coincide [7]. That way, a well-handled extended WF-net can be live and bounded for the initial marking *m* = {*i*}.

**Definition 3.26 (Well-Structured).** *A WF-net PN is well-structured iff its extended net P N is well-handled.*

Due to the well-structuredness property, it is possible to deduce further properties from WF-nets. To decide if a well-structured WF-net is sound can be verified in polynomial time. Moreover, a sound well-structured WF-net is safe [7].

**Figure 3.14** Example of a live, safe, FC, but not well-structured WF-Net

**Figure 3.15** Example of a live, safe, AC, well-structured, but not FC WF-Net

SESE regions support applying specific reductions as well [200], i.e., net reduction methods allow transforming Petri nets into simpler nets while keeping properties of the initial net. Because the problem size of a net is reduced that way, net reductions can facilitate later analysis.

**Block-Structured Free-Choice WF-Nets:** Regarding the different identified net classes, it can be summarized that SMs admit no synchronization, MGs admit no conflicts, FCs admit no confusion, and ACs allow asymmetric confusion (but disallow symmetric confusion) [155]. When these subclasses are associated with block-structured models, it seems that SESE models already imply a certain "good structure" as well. However, the subsequent counter-examples are constructed to show that block-structured models do not necessarily imply free-choice or even asymmetric choice. There are live bounded free-choice WF-nets that are not wellstructured (Figure 3.14) as well as well-structured live bounded WF-nets that are not free-choice (Figure 3.15) or not even AC (Figure 3.16).

To unite the advantages of free-choice and block-structured models for the control flow of the process, this thesis assumes WF-nets that are both FC and SESE. Besides the already illustrated mild computational aspects of FC nets and block-structured models, working with a block structure that allows for all required modeling constructs will be beneficial for modeling further constructs into the model as well.

**Figure 3.16** Example of a live, safe, well-structured, but neither FC nor AC WF-Net

**Figure 3.17** Example of a live, safe, well-structured, and now also FC WF-Net

In particular, such SESE regions will help to identify blocks, for which parts of the authorization policy and constraints have to be modeled, namely, blocks that encode sequential, exclusive, parallel, and loop patterns. Loops, or loop-affected blocks, can be identified easily because the block structure explicitly determines how loops may occur.

Still, there may be the problem that a given block-structured WF-net model is not free-choice. However, for the envisaged WF-net type, this is a surmountable difficulty because there are transformations for arbitrary Petri nets into free-choice nets [124, 187, 188]. In general, such transformations increase the structural complexity of the nets, in particular the number of nodes and arcs. However, given block-structured models, the considered NFC nets are not that "arbitrary" anymore and already show such a structural limitation that they can often be transformed into a free-choice net by means of only a few modifications. For example, to make the net from Figure 3.15 free-choice, only a single so-called silent transition (which merely acts for routing purposes) and a single place needs to be added (see Figure 3.17). Thus, the increase in the structural complexity that the transformation requires remains moderate. However, such a modification, consequently extends the state space. It creates intermediate steps and intermediate states, which must be considered as such to ensure the interpretation of the original net.

To illustrate a comprehensive example of such a WF-net net, the CEW process from the previous chapters will be considered again. As indicated before, there are straightforward transformations into Petri nets for a subset of BPMN elements. Figure 3.18 depicts this basic mapping that goes back to Dijkman et. al [79]. Due to the block-structure of the BPMN model in Figure 3.19, transforming the BPMN model results in a block-structured and also free-choice Petri net, which can be seen in Figure 3.20.

#### **3.1.2.5 Policy-Aware Workflow Net**

To prepare a directly processable formal input for the approach that entails not only the so far emphasized control flow of the process but also the whole process specification, the definitions of authorizations and constraints will also be directly related to the WF-Net. This will prepare a process-oriented definition of the policy as well. The definitions are adapted from the WSP-related works of Crampton et al. [49, 60] because they allow for a simple, though, comprehensive representation of authorization and relevant constraints.

**User-Task Authorization:** In practice, the authorization policy will not explicitly be defined as a user-task authorization. Instead, the authorization policy will be inferred from typical access control data structures [58]. Because, for common access control policies (e.g., RBAC), it is straightforward to derive the tasks for which users are authorized, a user-task authorization will be used in order to simplify the exposition. By making the inputs simple, the idea of keeping the net constructs involved as simple as possible, as described in the introduction to this chapter, is underlined.

**Definition 3.27 (User-Task Authorization).** *Because the transitions into a WF-net represent tasks, given a workflow net N* = -*P*, *T* , *F*, *m*0 *and a set of users U, an authorization policy (or a user-task authorization) for N can be denoted as a relation T A* ⊆ *U* × *T , which may be represented as a set of authorization lists A* = {*T A*(*u*) : *u* ∈ *U*}*, where T A*(*u*) = {*t* ∈ *T* : (*u*, *t*) ∈ *T A*} *denotes the set of tasks for which u is authorized. Analogously, it may be represented as a set of task-assignment lists T A* = {*T A*(*t*) : *t* ∈ *T* }*, where T A*(*t*) = {*u* ∈ *U* : (*u*, *t*) ∈ *T A*} *denotes the set of users that are authorized for t. User u is authorized to perform task t* iff (*u*, *t*) ∈ *T A. It is assumed that for every task t* <sup>∈</sup> *T , there is some user u* <sup>∈</sup> *U such that* (*u*, *<sup>t</sup>*) <sup>∈</sup> *T A*6.

For example, the user-task authorization depicted in Figure 3.21(a) is formalized as *T A* = {(*Alice*, *t*1), (*Alice*, *t*2), (*Bob*, *t*1)}, the authorization list as *T A*(*Alice*) = {*t*1, *t*2} and *T A*(*Bob*) = {*t*1}.

<sup>6</sup> This implies that trivial cases of unsatisfiability are avoided.

**Constraints:** As mentioned before, although further constraints regarding workflow satisfiability analysis have already been investigated [61], the focus is on common user-independent constraints, namely SoD/BoD-related binary constraints, which suffice to reach an obstructed state (ROA-4). For the sake of completeness, it should be mentioned that an authorization list may be interpreted as a unary constraint as well, where the scope of the constraint is a single task [50]. However, as elaborated in Chapter 2, a separated view on these both types will be maintained.

**Figure 3.18** Basic BPMN to WF-net patterns

**Figure 3.19** CEW process in BPMN

**Definition 3.28 (Constraints).** *A constraint c* ∈ *C may be viewed as a pair* (*Tc*, )*, where Tc* ⊆ *T is the scope of c and is a set of functions from Tc* to *U, specifying the assignments of steps in Tc to users in U that satisfy the constraint. In practice, the elements of are not enumerated. Instead, its members are defined by implicitly using some constraint-specific syntax. For example,* (*t*, *t* ,ρ) *can be written, where t*, *t* ∈ *T* and ρ *is a binary relation defined on U, to denote a constraint that has scope* {*t*, *t* } *and is satisfied by any assignment* π : *T* → *U such that* (π(*t*), π(*t* )) ∈ ρ*. In particular, the separation-of-duty constraint* (*t*, *t* , =) *requires t* and *t to be performed by different users. Similarly, the binding-of-duty constraint* (*t*, *t* , =) *requires t* and *t to be performed by the same user.*

For example, the SoD constraint indicated in Figure 3.21(b)can be denoted as (*t*1, *t*2, =). Although the focus is on such SoD and BoD constraints, the possibilities of considering further constraints will be addressed as well at the end of this chapter. Based on these definitions, it is now possible to define the input for the approach, namely a policy-aware workflow net. It comprises a WF-net with policy formalizations tailored to it and thus bundles the different aspects of a securityaware process specification. In other words, it contains all inputs required for the desired representation.

**Definition 3.29 (Policy-aware Workflow Net).** *A policy-aware workflow net <sup>N</sup> pol is represented as a tuple* -*N*, *U*, *T A*,*C, where N is a WF-net, U is a set of users, T A* ⊆ *U* × *T is the u*ser-task authorization, and *C is a set of constraints.*

Thus, the complete security-aware specification of the DMV process can, for example, now be formalized as a policy-aware WF-net *<sup>N</sup> pol* = -*N*, *U*, *T A*,*C*, where *N* = -{*p*1, *p*2, *p*3},{*t*1, *t*2},{*p*1, *t*1,*t*1, *p*2,*p*2, *t*2,*t*2, *p*3},-1, 0, 0, *U* = {*Alice*, *Bob*}, *T A* = {(*Alice*, *t*1), (*Alice*, *t*2), (*Bob*, *t*1)}, and *C* = {(*t*1, *t*2, =)}.

**Figure 3.20** Comprehensive example of a block-structured free-choice WF-net

**Figure 3.21** Determine the market value [39]

### **3.2 The SecANet Solution**

This section proposes the SecANet approach as a way to analyze and capture process obstructions in PAISs. Its methodology will allow the flattening of a workflow and the corresponding authorization data into a Security-Aware Petri net (which gives the approach its name). That way, a process representation that not only includes functional and behavioral but organizational process aspects as well emerges. Besides desirable Petri net properties, language-related properties are of particular interest to examine the behavior of the different process aspects in the resulting representation. In this regard, the approach is supposed to preserve the integrity of all process aspects involved, which will be regarded on different levels.

• **Integrity of Inputs:** In this thesis, the different process aspects manifest themselves in the process model and its policies. Each such input constitutes a common (abstract) representation used in a PAIS. The encoding of such input is supposed to preserve its initial behavior. Moreover, it should be possible to unambiguously retrace results from the representation back to given inputs. In case of an obstruction, this allows deducing conclusions or improvements for the process design.

• **Integrity of the Overall Representation:** The representation is supposed to provide a consistent full picture of the overall process in a PAIS. For this, the overall representation needs to preserve the behavior of the initial inputs. Moreover, each part of the overall representation is supposed to allow traceability to its corresponding initial input as well.

Based on an example, this section will first depict the general idea behind the principle of flattening and resulting possibilities for analyses. For behavioral observation, it will first be sufficient to consider related full firing sequences. A more thorough language-oriented examination will be performed after the introduction of the SecANet definitions. Based on the example, the approach will be generalized for authorization policies as well as SoD and BoD constraints. That way, based on a WFnet, obstructions can be captured with an "obstruction marking". The representation will already be prepared in such a way that it will allow encoding cycles (loops) as well. For the sake of simplicity and efficiency, this generalized encoding will be described on acyclic nets first. After introducing the formal basis for languagerelated observations on Petri nets, this section will decompose the approach to

**Figure 3.22** The SecANet approach

examine its language. The resulting SecANet language will allow investigating the behavioral integrity of inputs as well as the integrity of the overall process. Then, nets containing cycles will be introduced. They have a more complex encoding but preserve the idea of the encoding described in the acyclic case. An example will show the flattening of a process specification that involves a comprehensive workflow structure. It will be used to illustrate obstructability analysis resulting from the execution semantic of a SecANet.

#### **3.2.1 The Principle of "Flattening"**

Figure 3.22 depicts the SecANet approach, in particular, its idea of flattening: Based on a policy-aware workflow net (Definition 3.29), the policy is supposed to be encoded into the given workflow net step by step. As elaborated before, the authorization and constraints can be understood in a process-oriented way. User-task authorization is the process of granting user access to execute a specific task. Constraints impose restrictions on this authorization process. Because the assignment of a user to a task can only be done before its execution, the general idea is to model policy specific sub-processes that operate as a precondition to the actual activities of the control flow of the business process. In the context of Petri nets, this means that a task (transition) affected by the policy may only be enabled if the corresponding

**Figure 3.23** Flattening authorization and SoD into the DMV WF-net

user-task authorization or constraint is fulfilled. Thus, the idea is to put a net construct that models the part of the policy required to execute the corresponding task in each pre-area of the respective transition. Based on this general idea, the principle of flattening will first be described with the help of the example policy for the DMV process presented in Figure 3.21. Here, the authorization policy and constraints will be flattened into the DMV WF-net step by step. The resulting net will illustrate how the states provided by Petri nets can be used to capture an obstruction and how to analyze satisfiability and obstructability. Thereby, desirable Petri net properties and characteristics against the background of the established requirements will be indicated. A more detailed examination of the properties of the created net constructs will follow along with the generalization of the approach.

#### **3.2.1.1 Modeling Authorization**

Because of the absence of ambiguous gateways in the BPMN model of the DMV process, the workflow can straight-forwardly be transformed into the WF-net in Figure 3.1. For better clarity, the input place *p*<sup>0</sup> of the WF-net will subsequently be represented by *pi* and the output place *p*<sup>2</sup> by *po*. To model access control, the simple access control model without roles from Figure 3.21a is assumed, namely *T A* = {(*u*1, *t*1), (*u*1, *t*2), (*u*2, *t*1)}. Such user-task authorizations represent safety properties that explicitly state what is allowed. As mentioned before, a user-task authorization can also be regarded as a unary constraint that relates authorized user accesses to the scope of a single task. These possible assignments of users to tasks are mutually exclusive since only one of the authorized users can eventually be assigned to execute a task. Based on these considerations, Figure 3.23a depicts the first flattening step of the DMV WF-net example. It illustrates the initial user-task authorization and its flattened counterpart with authorization-related Petri net elements (the Petri net construct above the initial WF-net). The user-task assignments encode the corresponding transitions. For example, transition *tu*1*t*<sup>1</sup> encodes that user *u*<sup>1</sup> is permitted to access *t*1. Each transition pre-area consists of the same single incoming place marked with a single token such that a mutually exclusive choice must be made. Hence, a marked incoming place represents the state in which no user has yet been assigned to the corresponding task. It enables all transitions that encode the possible user-task assignments provided by the authorization policy for the corresponding task. Firing *tu*1*t*<sup>1</sup> , for instance, then represents the decision that *u*<sup>1</sup> is assigned to the execution of task *t*1. In the post-area of all user-task transitions corresponding to the same task, there is the same single outgoing place. The firing of *tu*1*t*<sup>1</sup> , for example, then produces a single token in this place. Hence, a marked outgoing place indicates the state that a user has been assigned to a task. However, the related task has not yet been executed. That way, pre-assignments (ROA-1) may also be considered (in case of the unordered version of obstructability, cf. Chapter 2).

Based on this example encoding, the full and terminal firing sequences can now be observed. For a more intuitive understanding of the net behavior, the number of possible permutations of theses sequences is limited by conducting a "lazy" workflow-oriented execution. This execution strategy aims to complete the workflow with the least effort by always trying to execute the workflow tasks in the first place. If some next workflow is not executable, the transitions in its pre-area are fired in such a way that they reach an enabling marking for that task. Based on this, the set of full and the set of terminal firing sequences for the WF-net with authorization, where *mstart* = {*p*1, *pt*1−, *pt*2−}, and *mend* = {*p*3}, is

$$F\_{SN\_{TA}} = \{ \langle t\_{\mathcal{U}\_1\mathcal{I}\_1}, t\_1, t\_{\mathcal{U}\_1\mathcal{I}\_2}, t\_2 \rangle, \\
$$

$$\langle t\_{\mathcal{U}\_2\mathcal{I}\_1}, t\_1, t\_{\mathcal{U}\_1\mathcal{I}\_2}, t\_2 \rangle \},$$

$$and$$

$$\mathcal{T}\_{\mathcal{N}\_{TA}} = F\_{SN\_{TA}}.$$

The individual user-task transitions directly indicate (and allow to retrace) the underlying authorization policy (e.g., as a user-activity matrix), thus preserving the behavior of the exemplary user-task authorization input *T A* = {(*u*1, *t*1), (*u*1, *t*2), (*u*2, *t*1)}.

#### **3.2.1.2 Modeling Constraints**

Contrary to the authorization policy, which determines allowed user-task assignments, constraints specify safety properties that explicitly state violations (i.e., what is not allowed). These constraints act upon the authorization policy and are mutually exclusive for the respective user-task assignments between two (sets of) tasks (i.e., binary constraints). More specifically, constraints mutually exclude that the same user is assigned to a scope of tasks (SoD) or that different users are assigned to a scope of tasks (BoD). That way, constraints restrict possible user-task assignments. Consequently, only users authorized for the tasks that lie in the scope of a constraint can be constrained at all. Hence, there is the implicit assumption that the users affected by an SoD or BoD constraints are part of the user-task authorization as well. For Petri net modeling, this means that constraints are supposed to act upon the user-task assignment transition and do not operate on the tasks themselves for which they are defined (although, for example, the constraint (*t*1, *t*2, =) itself may suggest this). Hence, the envisaged encoding of constraints is supposed to restrict the given user-task assignments.

Regarding the modeling of constraints, it can be observed that a Petri net without any places and a non-empty set of transitions allows for any "unconstrained" behavior involving the activities represented by these transitions. Adding a place can then be compared to the introduction of a constraint. The underlying fundamental idea of Petri nets is that transitions are independent (i.e., concurrent) unless specified otherwise [1]. Concurrency also applies to the occurrence of the user-task assignments for different tasks because they occur independently from other task-assignments. Hence, places that establish relations between the user-task transitions for different tasks can be used to constrain their occurrence as well. In particular, such places can be used to model a choice (or conflict) between the user-task transitions for different tasks. For a BoD constraint on two tasks, the choice, which of the users executes both tasks, has to be made. This choice then means that all other user-task assignments involving other users for the given tasks are excluded. For an SoD constraint on two tasks, the choice, which of the users executes the one or the other task, has to be made.

The introductory example will focus on SoD constraints to illustrate the idea behind constraint modeling. These observations will then be used for the generalization of constraint modeling, where BoD constraints will be covered as well. For tasks affected by an SoD constraint, a place is added for every two corresponding user-task assignments. The place is then connected to the user-task assignment transitions. It encodes a choice between the connected transitions. That way, such a place and its outgoing arcs pointing to the involved two user-task transitions in conflict reflect an SoD constraint on the two activities for which the same user is authorized. Based on this, the example in Figure 3.23 shows how the SoD constraint (*t*1, *t*2, =) can be flattened into the WF-net with authorization (highlighted in red). By introducing the place encoding choice (or, "choice-place"), denoted as "SoD", the set of full firing sequences, where *mstart* = {*p*1, *pt*1−, *pt*2−, *pSoD*} and *mend* = {*p*3} is constrained (depicted by a comparison with the full firing sequences of *SNT A*+*SoD* ):

$$F\_{\mathcal{S}\mathcal{N}\_{TA+\mathcal{S}\circ D}} = \langle \overleftarrow{\langle t\_{\mathcal{U}\mathcal{A}+\tau}} t\_{\mathcal{T}}, \overleftarrow{t\_{\mathcal{U}\mathcal{A}+\mathcal{S}\circ D}} \rangle,$$

$$\langle t\_{\mathcal{U}\_2\iota\_1}, t\_1, t\_{\mathcal{U}\_1\iota\_2}, t\_2 \rangle \rangle.$$

Hence, only the latter firing sequence of*SNT A*+*SoD* meets the SoD constraint. The set of terminal firing sequences is now not in accordance with the full firing sequences anymore.

$$\begin{aligned} \mathcal{T}\_{\mathcal{N}\_{T A + \text{So} D}} &= \{ \langle t\_{\mathfrak{u}\_1 t\_1}, t\_1 \rangle, \\ & \langle t\_{\mathfrak{u}\_2 t\_1}, t\_1, t\_{\mathfrak{u}\_1 t\_2}, t\_2 \rangle \}. \end{aligned}$$

Based on this, it can be observed that the set of full firing sequences is reduced. More specifically, the terminal firing sequences of the user-task authorization construct is restricted by the modeled constraint. Although each transition is enabled for some marking of the net (i.e., it is simply live), this may not mean that all enabled transitions are part of a single full firing sequence. The full firing sequences themselves stay the same. Hence, only the latter firing sequence meets the SoD constraint in the example and some full firing sequences are not allowed anymore. However, it can be noted that the leftover full firing sequences do not change in themselves. This will be of particular interest for behavioral observations.

#### **3.2.1.3 Example SecANet Analysis**

Given that the authorization policy and constraints have now been flattened into the SecANet example with the initial marking represented in Figure 3.23b, playing the token game is going to show how it can be used for analysis and to capture an obstructed state. The set of (full) firing sequences encompasses not only the process activities and their execution order but also the information who is assigned to the corresponding activities or tasks. Hence, the transition firing sequences of a SecANet can be regarded as traces that can be used to check which safety and liveness security properties they may or may not fulfill. Because safety properties are encoded and enforced by the flattening of the policy, the examination of the liveness of the overall system is of particular interest, i.e., if the WF-net execution can be completed with the given policy (or, in other words, if the process goal can be achieved).

**Figure 3.24** Obstructed marking in flattened WF-net

**Satisfiability:** Chapter 2 has already shown that the DMV process and its policy is satisfiable. The example SecANet can now be used to illustrate this as well. By firing *tu*2*u*<sup>1</sup> (*u*<sup>2</sup> is assigned to *t*1) and firing *t*<sup>1</sup> (the execution of the first task), followed by firing *tu*1*t*<sup>2</sup> (*u*<sup>2</sup> is assigned to *t*2) and then firing *t*<sup>2</sup> (the execution of the second task), the output place is marked. This means that the workflow and its policy are satisfiable. Thus, satisfiability can be assessed by looking at the set of full firing sequences of the SecANet, which is {*u*2*u*1, *t*1, *u*1*t*2, *t*2} for the system net *SN*SecANet = (*N*SecANet, *mstart*, *mend* ), where *mstart* = {*pi*, *pt*1−, *pt*2−, *pSoD*} and *mend* = {*po*}. Concerning the WSP, the set of full firing sequences represents synthesized plans to conduct satisfiable workflow executions. If such plans exist, such sequences fulfill the safety properties given by the policy as well as the liveness property of process completion. An empty set of full firing sequences would therefore mean that the workflow is not satisfiable.

**Capturing Obstructions:** As identified in Chapter 2, besides its satisfiability, the respective process specification inherits an obstruction. By playing the token game again, the obstruction can easily be identified. More specifically, firing *tu*1*t*<sup>1</sup> and *t*<sup>1</sup> (*t*<sup>1</sup> has been executed by *u*1) results in an obstructed state, in which no further transition is enabled (as illustrated in Figure 3.24). This state of obstruction can be denoted by the marking *m*<sup>⊗</sup> = {*p*1, *pt*2−}, where ⊗ is the symbol that denotes "obstruction" (in its abbreviated form "ox"). The obstructing execution sequence can be denoted by σ<sup>⊗</sup> = *u*1*t*1, *t*1. The reachability of this obstructed marking can be denoted by *m*0[*tu*1*t*<sup>1</sup> , *t*1*m*⊗. Hence, there is a decisive difference between the two nets, which can be observed if not only the full firing sequences but all terminal firing sequences are considered. Such terminal firing sequences only reach markings in which no further transition is enabled, and which are also known as "deadlock markings". For the WF-net with authorization *NT A*, the terminal firing sequences are just the same as its full firing sequences *SNT A* . However, after adding the SoD constraint, the set of full firing sequences *SNT A*+*SoD* loses a sequence of *SNT A* . Moreover, *<sup>T</sup>NT A*+*SoD* now contains the additional terminal firing sequence *tu*1*t*<sup>1</sup> , *t*1, which does not reach the intended final marking (and is thus not in the set *SNT A*+*SoD* ). Still, *tu*1*t*<sup>1</sup> , *t*1 is a feasible sequence of transitions. It only contains the first two transitions of the missing full firing sequence *tu*1*t*<sup>1</sup> , *<sup>t</sup>*1, *tu*1*t*<sup>2</sup> , *<sup>t</sup>*2 of *SNT A* and represents a synthesized partial plan, which, however, leads to an obstruction. Hence, based on a WF-net with authorization, the modeling of constraints can now, for the first time, lead to deadlocks in the resulting nets, in the sense that the output place *po* of the WF-net can no longer be reached. Such a deadlock manifests the obstructive conflict between the organizational aspect and the functional aspect of the workflow. Hence, apart from the end marking, a marking in a SecANet, in which no transition is enabled, represents an obstructed state. Here, a decisive advantage of Petri nets comes to light. They allow having a single representation of the system that captures the event sequences and the state at the same time. In this way, Petri nets do not only record how the obstruction occurred but they also capture the system state of the obstruction of the affected process in a PAIS. That way, a SecANet can be used to synthesize partial plans that encode obstructed workflow executions. Such obstructed partial plans or sequences fulfill and enforce the policybased safety properties as well. However, these partial plans lack in satisfying the liveness property of process termination, i.e., they can not be used to complete the workflow.

**Obstructability:** Obstructability analysis is supposed to detect and capture obstructions. Based on the observations from the example, deadlocks that do not reach the final marking indicate obstructions. For small nets, such obstruction markings can be found by hand, for example, with the token game as done above. For bigger Petri nets, there is a variety of methods for analyzing and detecting deadlocks, which is a fundamental issue in Petri net analysis [45, 51, 157, 219]. Their suitability will be illustrated after the subsequent generalization of the flattening example.

#### **3.2.2 Generalizing Flattening**

Based on the presentation of the basic idea of flattening, the SecANet approach will subsequently be generalized. The aim is to flatten the user-task authorization *T A* and the set of constraints *<sup>C</sup>* of a policy-aware workflow net *<sup>N</sup> pol* = -*N*, *U*, *T A*,*C* into a single net *NT A*+*C*. As a first step, the user-task authorization *T A* is considered and encoded into the net *NT A*. Based on this, further SoD and BoD constraints are flattened into the net, denoted by *NT A*+*CSoD* and *NT A*+*CBoD* .

#### **3.2.2.1 Flattening of User-Task Authorization**

As described before, the user-task authorization is flattened with the intention that for every possible assignment, a transition denoted by user and transition name (e.g., *tu*1*t*<sup>1</sup> ) is introduced. Each user-task transition can consume tokens from the single place marked with a single token. This ensures that the transition can only be executed once by a specific user. Moreover, this user can execute the corresponding task only once.

**Definition 3.30 (Flattening User-Task Authorization).** *Given a policy-aware workflow N pol* = -*N*, *U*, *T A*,*C, flattening the user-task authorization T A into N is as follows:*


*PT A* = *P* ∪ {*pt*1−, *pt*2−,..., *pti*−}∪{*pt*1+, *pt*2+,..., *pti*+}, *TT A* = *T* ∪ {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> , *tu*2*t*<sup>1</sup> , *tu*2*t*<sup>2</sup> ,..., *tu <sup>j</sup> ti*}, *FT A* = *F* ∪ {*pt*1−,*tu*1*<sup>t</sup>* <sup>1</sup> ,*pt*2−,*tu*1*<sup>t</sup>* <sup>2</sup> ,*pt*1−,*tu*2*<sup>t</sup>* <sup>1</sup> ,*pt*2−,*tu*2*<sup>t</sup>* <sup>2</sup> ,..., *pti*−,*tu <sup>j</sup> <sup>t</sup> i* } ∪ {*tu*1*t*<sup>1</sup> , *pt*1+,*tu*1*t*<sup>2</sup> , *pt*2+,*tu*2*t*<sup>1</sup> , *pt*1+,*tu*2*t*<sup>2</sup> , *pt*2+,..., *tu <sup>j</sup> ti*, *pti*+} ∪ {*pt*1+, *t*1,*pt*2+, *t*2,...,*pti*+, *ti*} and the marking *mT A*<sup>0</sup> = -1, 0, 0,..., 0, 1, 0, 1, 0,..., 1, 0 with *mT A*<sup>0</sup> according to the order *pinput*, *p*2,..., *pout put*, *pt*1−, *pt*1+, *pt*2−, *pt*2+,..., *pti*−, *pti*+.

The five steps from Definition 3.30 are applied to the running example based on its net *N* and the user-task authorization *T A*. First, the places *pt*1−, *pt*1<sup>+</sup> , *pt*2−, and *pt*2<sup>+</sup> are created for the transitions *t*<sup>1</sup> and *t*2, and *pt*1<sup>−</sup> and *pt*2<sup>−</sup> are marked with one token. Afterwards, the user-task transitions *tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> , and *tu*1*t*<sup>2</sup> are created based on the user-task authorization. Then, the arcs *pt*1−,*tu*1*<sup>t</sup>* <sup>1</sup> and *pt*1−,*tu*2*<sup>t</sup>* 1 are created for *pt*1<sup>−</sup> and its corresponding transitions *tu*1*t*<sup>1</sup> and *tu*2*t*<sup>1</sup> , and the arc *pt*2−,*tu*1*<sup>t</sup>* <sup>2</sup> is created for *pt*2<sup>−</sup> and its transition *tu*1*t*<sup>2</sup> . After that, the arcs *tu*1*t*<sup>1</sup> , *pt*1+ and *tu*2*t*<sup>1</sup> , *pt*1+ are created for transitions *tu*1*t*<sup>1</sup> and *tu*2*t*<sup>1</sup> and its corresponding place *pt*1+, and the arc *tu*1*t*<sup>2</sup> , *pt*2+ is created for *tu*1*t*<sup>2</sup> and its corresponding place *pt*2+. The idea of the last step is to then connect all the created Petri net parts with the initial WF-net, which is realized by adding arcs from *pt*1+, *t*1 to *pt*2+, *t*2. That way, *T A* is flattened into the WF-net *N*, which results in the net *NT A*, where *PT A* = {*p*1, *p*2, *p*3, *pt*1−, *pt*1+, *pt*2−, *pt*2+}, *TT A* = {*t*1, *t*2, *tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> },

*FT A* = {*p*1, *t*1,*p*1, *t*2 *t*2, *p*3*pt*1−,*tu*1*<sup>t</sup>* <sup>1</sup> ,*pt*1−,*tu*2*<sup>t</sup>* <sup>1</sup> ,*pt*2−,*tu*1*<sup>t</sup>* <sup>2</sup> ,*tu*1*t*<sup>1</sup> , *pt*1+, *tu*2*t*<sup>1</sup> , *pt*1+,*tu*1*t*<sup>2</sup> , *pt*2+} and the marking *mT A*<sup>0</sup> = {*p*1, *pt*1−, *pt*2−}.

#### **3.2.2.2 Flattening of SoD Constraints**

Figure 3.25a depicts the encoding of SoD constraints. The basic idea behind the flattening of SoD constraints is to introduce a choice-place for all users authorized for conflicting tasks (as depicted in Figure 3.23b). Hence, choice-places are added for every user-task transition pair involving the same user for the tasks affected by the constraint. Every such choice-place will then prevent the firing of a user-task transition containing the same user. Moreover, arcs are added from each choiceplace to every conflicting user-task transition pair. Note that an SoD choice-place is introduced only for user-task assignments that conflict with each other (see *SoDu*<sup>1</sup> and *SoDu*<sup>2</sup> ). Furthermore, the restriction on the sequential execution of *ti* and *tj* can be dropped, e.g., *ti* and *tj* can be concurrent (as reflected in Figure 3.25a).

**Definition 3.31 (Flattening SoD Constraints).** *Given a policy-aware workflow net N pol* = -*N*, *T A*,*C, after transforming the user-task authorization T A into N resulting in NT A (according to Definition* 3.30*), flattening of SoD constraints cSoD* ∈ *C of the form* (*tk* , *tl*, =) *into NT A is as follows:*



These two steps are exemplified with the SoD constraint (*t*1, *t*2, =) of the running example. First, an SoD place *SoDu*1*t*1*t*<sup>2</sup> is created for the user-task-transition pair *tu*1*t*<sup>1</sup> and *tu*1*t*<sup>2</sup> , and one token is added to it. Secondly, the arcs -*SoDu*1*t*1*t*<sup>2</sup> , *tu*1*t*<sup>1</sup> and -*SoDu*1*t*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> are created to make the SoD place act as a choice place (see Figure 3.23b). Flattening *cSoD* into the net *NT A* results in the net *NT A*+*SoD*, with *PT A*+*SoD* = {*p*1, *p*2, *p*3, *pt*1−, *pt*1+, *pt*2−, *pt*2+, *SoDu*1*t*1*t*<sup>2</sup> }, *TT A*+*SoD* = {*t*1, *t*2, *tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }, *FT A*+*SoD* = {*p*1, *t*1, *p*1, *t*2 *t*2, *p*3*pt*1−,*tu*1*<sup>t</sup>* <sup>1</sup> ,*pt*1−,*tu*2*<sup>t</sup>* <sup>1</sup> ,*pt*2−,*tu*1*<sup>t</sup>* <sup>2</sup> ,*tu*1*t*<sup>1</sup> , *pt*1+,*tu*2*t*<sup>1</sup> , *pt*1+, *tu*1*t*<sup>2</sup> , *pt*2+-*SoDu*1*t*1*t*<sup>2</sup> , *tu*1*t*<sup>1</sup> ,-*SoDu*1*t*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> } and the marking *mT A*+*SoD*<sup>0</sup> = {*p*1, *pt*1−, *pt*1−, *SoDu*1*t*1*t*<sup>2</sup> }. Figure 3.25b depicts this net, which is just the net of

#### **3.2.2.3 Flattening of BoD Constraints**

Figure 3.23a with additional place annotations.

Fig. 3.26(a) depicts how BoD constraints are encoded. Here, choice places are added as well. However, the arcs are connected differently. The idea is that, for a BoD constraint on two tasks, every choice place aims to prevent the firing of a usertask transition that contains another user. Therefore, for each user-task assignment transition for a task, a choice place is introduced and connected to that user-task transition. Then, from each choice place, arcs are added to every user-task transition for the other task that does not contain the user for which the choice place has been introduced. Note that, just like in SoD flattening, *ti* and *tj* can be concurrent.

**Definition 3.32 (Flattening BoD Constraints).** *Given a policy-aware workflow net N pol* = -*N*, *U*, *T A*,*C, after transforming the user-task authorization T A into N resulting in NT A (according to Definition* 3.30*), flattening of BoD constraints cBoD* ∈ *C of the form* (*tk* , *tl*, =) *into NT A is as follows:*


*Analogous to NT A*+*SoD, after performing these steps, the net NT A*+*BoD* = -*PT A*+*BoD*, *TT A*+*BoD*, *FT A*+*BoD*, *mT A*+*BoD*<sup>0</sup> *is obtained, where*

*PT A*+*BoD* = *PT A* ∪ {*BoDu*1*t*1*t*<sup>2</sup> , *BoDu*2*t*1*t*<sup>2</sup> ,..., *BoDu <sup>j</sup> tk tl*}, *TT A*+*BoD* = *TT A*, *FT A*+*BoD* = *FT A* ∪ {-*BoDu*1*t*1*t*<sup>2</sup> , *tu*1*t*<sup>1</sup> }∪{-*BoDu*1*t*1*t*<sup>2</sup> , *tut*<sup>2</sup> |*tut*<sup>2</sup> ∈ *TT A*−{*tu*1*t*<sup>2</sup> }∧*u* ∈ *U*∧(*u*, *t*2) ∈ *T A*} ∪ {-*BoDu*2*t*1*t*<sup>2</sup> , *tu*2*t*<sup>1</sup> }∪{-*BoDu*2*t*1*t*<sup>2</sup> , *tut*<sup>2</sup> |*tut*<sup>2</sup> ∈ *TT A*−{*tu*2*t*<sup>2</sup> }∧*u* ∈ *U*∧(*u*, *t*2) ∈ *T A*} ∪ ... ∪ {-*BoDu <sup>j</sup> tk tl*, *tu <sup>j</sup> tk* }∪{-*BoDu <sup>j</sup> tk tl*, *tutl*|*tutl* ∈ *TT A* −{*tu <sup>j</sup> tl*}∧*u* ∈ *U* ∧(*u*, *tl*) ∈ *T A*} *and the marking mT A*+*BoD*<sup>0</sup> = -1, 0, 0,..., 0, 1, 0, 1, 0,..., 1, 0, 1, 1,..., 1 *with mT A*+*BoD*<sup>0</sup> *according to the order pinput*, *p*2,..., *pout put*, *pt*1−, *pt*1+, *pt*2−, *pt*2+,..., *pti*−, *pti*+, *BoDu*1*t*1*t*<sup>2</sup> , *BoDu*2*t*1*t*<sup>2</sup> ,..., *BoDu <sup>j</sup> tk tl* .

To illustrate this, suppose that the SoD constraint in the example is replaced by the BoD constraint (*t*1, *t*2, =), such that the computation of the market value (*t*1) and its control (*t*2) is supposed to be done by the same user. Applying the first step of Definition 3.32 then creates the place *BoDu*1*t*1*t*<sup>2</sup> for the user-task transition *tu*1*t*<sup>1</sup> and *BoDu*2*t*1*t*<sup>2</sup> for *tu*2*t*<sup>1</sup> . Secondly, the arcs -*BoDu*1*tk*<sup>11</sup> , *tu*1*t*<sup>1</sup> are created. Here, the second arc can not be created because there is no other user-task transitions for *t*<sup>2</sup> than *tu*1*t*<sup>2</sup> . Then, the arcs -*BoDu*2*tk*<sup>11</sup> , *tu*2*t*<sup>1</sup> and -*BoDu*2*tk*<sup>11</sup> , *tu*1*t*<sup>2</sup> are created. Flattening *cBoD* into the net *NT A* results in the net *NT A*+*BoD*, with *PT A*+*BoD* = {*p*1, *p*2, *p*3, *pt*1−, *pt*1+, *pt*2−, *pt*2+, *BoDu*1*t*1*t*<sup>2</sup> , *BoDu*2*t*1*t*<sup>2</sup> }, *TT A*+*BoD* = {*t*1, *t*2, *tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }, *FT A*+*BoD* = {*p*1, *t*1, *p*1, *t*2, *t*2, *p*3,*pt*1−,*tu*1*<sup>t</sup>* <sup>1</sup> , *pt*1−,*tu*2*<sup>t</sup>* 1 , *pt*2−,*tu*1*<sup>t</sup>* <sup>2</sup> ,*tu*1*t*<sup>1</sup> , *pt*1+,*tu*2*t*<sup>1</sup> , *pt*1+,*tu*1*t*<sup>2</sup> , *pt*2+ -*BoDu*1*t*1*t*<sup>2</sup> , *tu*1*t*<sup>1</sup> , -*BoDu*2*t*1*t*<sup>2</sup> , *tu*2*t*<sup>1</sup> ,-*BoDu*2*t*1*t*<sup>2</sup> , *tu*1*t*<sup>2</sup> } and the marking*mT A*+*BoD*<sup>0</sup> = {*p*1, *pt*1−, *pt*2−, *BoDu*1*t*1*t*<sup>2</sup> , *BoDu*2*t*1*t*<sup>2</sup> }. Figure 3.26b depicts this net graphically.

#### **3.2.2.4 SecANet Obstructions**

Based on the SecANet flattening and the observations from the example, the state of obstruction and the affected WF-tasks can now be grasped formally. Obstructions may not only obstruct a single task during the execution of a workflow, as in the example. Depending on the structure of the considered process, for instance, in a parallel branch, multiple tasks may become obstructed at the same time in a single execution as well.

**Figure 3.25** Generalized SoD with application to simplified payment workflow

**Figure 3.26** Generalized BoD with application to simplified payment workflow

**Definition 3.33 (Obstruction Marking, Obstructed Task).** *Let NT A*+*<sup>C</sup> be a* SecANet *with an initial marking mo* ∈ *PT A*+*<sup>C</sup> and the output place po* ∈ *P of the WF-net N. Based on the set of reachable markings from mo, an obstruction marking m*<sup>⊗</sup> *represents a terminal marking that does not contain the output place po of the workflow net, i.e., m*<sup>⊗</sup> <sup>=</sup> *<sup>m</sup>* ∈ [*m*0 *iff t* ∈ *TT A*+*<sup>C</sup>* : *m*[*t and po m. Accordingly, the set of obstruction markings M*<sup>⊗</sup> *is represented by all* *obstruction markings, i.e., M*<sup>⊗</sup> = {*<sup>m</sup>* ∈ [*m*0|*<sup>t</sup>* <sup>∈</sup> *TT A*+*<sup>C</sup>* : *<sup>m</sup>*[*t* ∧ *po <sup>m</sup>*}*. Moreover, an obstructed task t*<sup>⊗</sup> *denotes the task of the WF-net that can not be executed due to an obstruction. It represents the post-area of a marked WF-place p*• *contained in the obstruction marking m*⊗*. Accordingly, the set of obstructed tasks for an obstruction marking m*<sup>⊗</sup> *in a workflow is defined as T*<sup>⊗</sup> = {*p*•|*p* ∈ *m*<sup>⊗</sup> ∧ *p* ∈ *P*}*.*

For example, the set of obstruction markings of the SecANet in Figure 3.24 is the singleton marking *M*<sup>⊗</sup> = {{*p*1, *pt*2−}}. The set of obstructed tasks for this obstruction marking is *T*<sup>⊗</sup> = {*p*• 1}={*t*2}. In contrast to the output place of the workflow determining complete workflow executions, it is not known which of all the other places will indicate an obstructed workflow execution. In this regard, it must be noted that there may be markings that do not represent terminal markings but already obstruct some workflow task(s). For example, there may still be enabled, rather non-relevant user-task transitions for tasks that were not supposed to be executed due to exclusive branching. However, especially regarding loops, one can, in general, not rule out that the firing of some user-task transition may not enable further transitions that eventually allow progression in the execution of the workflow. Therefore, in order to exclude such uncertainties, the more restrictive type of obstruction markings is assumed, i.e., markings in which no further transitions are enabled. Given such an obstructed marking, it can then be identified easily which workflow task(s) *t*<sup>⊗</sup> were affected by an obstruction and which of the fired user-task transitions were not relevant at all.

Due to the observations on satisfiability and obstructability in the example, the SecANet encoding allows defining obstructed and satisfiable workflow executions. On the one hand, transition sequences that reach markings that do not enable further transitions and moreover do not contain the output place of the WF-net represent obstructed workflow executions, or, in other words, obstructed partial plans. On the other hand, transition sequences that reach markings that contain the output place *p*<sup>0</sup> of the WF-net represent complete workflow executions, or, in other words, satisfiable execution plans.

**Definition 3.34 (Obstructed and Satisfiable Firing Sequences).** *The set of obstructed firing sequences can be denoted as <sup>T</sup>*⊗*NT A*+*<sup>C</sup>* = {<sup>σ</sup> <sup>|</sup> (*NT A*+*C*, *m*0)[σ(*NT A*+*C*, *m* )∧*<sup>m</sup>* ∈ [*m*0∧*t* ∈ *TT A*+*<sup>C</sup>* : *m* [*t*∧ *po <sup>m</sup>*}*. To adequately consider the case that an end marking may not only contain the place p*<sup>0</sup> *but there may be further tokens left, which were not consumed due to the given encoding, the system net to determine the set of full firing sequences is SNT A*+*<sup>C</sup>* = {*NT A*+*C*, *mo*, *mend* |*mend* ∈ [*m*0 ∧ *mend* ≥ *po*}*. Hence, the set of full firing sequences of the system* SecANet *SNT A*+*<sup>C</sup> represents complete satisfiable workflow executions. Based on this, the set of obstructed firing sequences can equivalently be defined by the set of terminal sequences without the set of full firing sequences, i.e., <sup>T</sup>*⊗*NT A*+*<sup>C</sup>* <sup>=</sup> *<sup>T</sup>NT A*+*<sup>C</sup>* <sup>−</sup> *SNT A*+*<sup>C</sup> .*

For example, the set of obstructed firing sequences of the SecANet in Figure 3.24 is *<sup>T</sup>*⊗*NT A*+*<sup>C</sup>* = {*tu*1*t*<sup>1</sup> , *t*1}. The set of full firing sequences of the system SecANet example is *SNT A*+*<sup>C</sup>* = {*tu*2*t*<sup>1</sup> , *<sup>t</sup>*1, *tu*1*t*<sup>2</sup> , *<sup>t</sup>*2}7. Full firing sequences (or plans) of a SecANet can be used to pre-assign all users to tasks before the actual execution of the WF-task. Such pre-assignment can be used to ensure, for example, that each task of the workflow can be executed and, that way, every potential execution sequence is feasible. However, such plans may encode that each user-task assignment is done only when required directly before the execution of the task (i.e., "on-demand", so to speak, or comparable to the "lazy" execution). In the latter case, if respective plans reach the end of the workflow, the user-task transitions of the tasks that have not been executed, e.g., due to exclusive branching, would still be enabled by the marking reached by the plan. However, although the marking resulting from a plan may still enable transitions, it always completes the workflow because its output place *po* is marked.

#### **3.2.2.5 Capturing Indicators by Costs**

Based on the previously identified need for an indicator-based process security that manifests itself in the requirement to consider costs (cf. Chapter 2), the SecANet representation is supposed to captures costs as well. That way, the basis for a security-sensitive solutions will be laid. Formally, to consider indicators in the SecANet, a cost function *<sup>c</sup>* : *<sup>T</sup>* , *<sup>P</sup>* <sup>→</sup> <sup>R</sup><sup>+</sup> can be defined to add costs to the

<sup>7</sup> Again, both sets of firing sequences consider a "lazy" workflow-oriented execution that pursues to execute WF-tasks in the first place.

nodes of the net (transitions or places). Graphically, such further information can be annotated to the respective net elements (i.e., the respective nodes), such that the SecANet places and transitions can be annotated with the costs. Based on different execution sequences and the costs assigned to the involved transitions, costs would allow to determine the least costly user-task assignment based on a certain utility function. For example, given that there would be multiple paths of a satisfiable firing sequences, based on the cost assigned to the user-task transition involved in these sequences, a least costly sequences (or execution plan) could be determined. Assigning costs to transitions will allow to express costs of user-task assignment decisions. Moreover, determining costs for places could encode the cost to add a token to certain places. Here, for example, a violation of a constraint could be encoded in order to allow for a user-task assignment that allows to complete an obstructed workflow execution. That way, even initially "impossible" or "violating" executions sequences could be considered as long as the associated cost would be lower than the risk of obstruction. That way, the SecANet encoding allows capturing indicators by costs. The consideration of these costs will particularly be relevant for finding solutions to obstructions, which will follow after this chapter.

#### **3.2.3 SecANet Properties**

Based on the provided generalization, it is now possible to observe the properties of SecANets. This elaboration will first consider the properties of the nets resulting from the flattening of the authorization policy. Afterwards, it will be regarded how the properties change when further constraints are encoded. Figure 3.25 and Figure 3.26 will serve to illustrate the properties of the respective user-task construct (labelings beginning with *u* ...) and the different constraint constructs (labelings beginning with *SoD* ..., *BoD* ..., respectively).

#### **3.2.3.1 Net Properties of Modeled User-Task Authorization**

The modeling intention for SecANets is to obtain **safe** (i.e., 1-bounded) nets. Safeness allows for decidability and staying within polynomial complexity bounds for a large number of Petri net problems [87], which aligns with the desire to construct nets that allow for efficient analyses. Moreover, safeness also addresses the requirement of behavioral integrity. It is strongly related to the condition and event principle, which can be connected to the way how Carl Adam Petri introduced his nets [162]. He decomposed state elements to such an extent that each component can be understood as a condition. Such a condition is fulfilled in some situations and is not in others. A token in a place then indicates that a condition is fulfilled. In this view, a place can have at most one token, just as a condition cannot be fulfilled more than once. If the firing of a transition resulted in a second token in a place, the condition and event principle would be violated. It would be considered as an error because the examined space of possible states of places as conditions is left (analogously, the division by 0 or the addition of a number with a truth value leave the intuition of division and addition for numbers). A system model that uses the intuitive term "condition" reasonably excludes such situations [173]. For example, in the aforementioned WF-nets, places represent conditions and transitions represent tasks (or events). The condition-event principle represents the guideline in the modeling of the user-task assignments based on an authorization policy as well. Assigning a user to a task conditions that no user has yet been assigned. The state of assignment is determined by the presence or absence of a token in the place indicating unassignment. The presence or absence of a token in the place indicating assignment determines that a user is assigned or not. The assignment, in turn, conditions the execution of the activity of the process, i.e., the task of the WF-net. The meaning of a place with two tokens, which might even be produced by different user-task transitions into the same place, would therefore be unclear and would constitute an error as well. This further implies that the net is plain (i.e., all arc weights are at most one).

Based on these considerations, the safeness of the authorization construct from Definition 3.30 will be examined. First, it can be observed that every user-task transition has the same pre- and post-area. Moreover, each transition introduced is bounded to fire only once due to the incoming place marked with a single token. z To limit the maximum number of tokens a place may contain, in particular, to obtain 1-boundedness, the Definition 3.30 mimics the so-called "complementaryplace transformation" (see Murata [155]). The complementary-place transformation creates additional net components in such a way that they ensure that the number of tokens in a place may not exceed the desired capacity. It first creates a complementary-place *p* for each place *p*. Subtracting the initial marking of the place *p* from the desired maximum number of tokens in the place *p* results in the initial marking of the place *p* . Then, for all transitions that are connected to each place *p*, complementary-arcs that connect the complementary-place *p* with the transitions in reverse order are created, i.e., an incoming (outgoing) arc of place *p* results in an outgoing (incoming) arc for the place *p* . That way, the sum of tokens for each pair of place *p* and its place-complement *p* equals the maximum number of tokens for each place *p* before and after firing the regarded transitions [155].

Hence, to show that each user-task construct itself (without its connection to the workflow task) is safe, its identical counterpart resulting from the application of the complementary-place transformation will subsequently be created. Based on the fundamental choice construct, the basic net depicted in Figure 3.27 models the choice between an arbitrary number of users to be assigned to a single task. Its place is marked with a single token because only one user-task transition is supposed to be selected. Moreover, based on the considerations on safeness above, the maximum number of tokens (i.e., the place capacity) is supposed to be "1" as well.

Based on this, a complementary-place *pt*+ is first built for each place *pt*−. Given that *pt*− is initially marked with a single token, and that this is also the maximum number of tokens *p* may contain, this results in an initial marking of *pt*− of zero tokens. Then, for all outgoing transitions connected to place *pt*−, incoming arcs are created that connect each transition with the complementary place *pt*+, as depicted in Figure 3.28. Hence, the net resulting from the complementary-place transformation of a basic net that models the choice between different transitions and whose maximal number of tokens is bound to 1 exactly models the task-specific authorization resulting from the steps 1-4 from Definition 3.30. Because the workflow task, which is added in the fifth step of Definition 3.30, only additionally consumes a token of the place indicating assignment *pt*+, it does not contribute to an increase of tokens at all.

In terms of the integrity of inputs, a user-task authorization modeled this way makes both the meaning of each possible state and the associated events (or transitions) unambiguous, thus ensuring traceability to the original authorization policy and its state in a PAIS. In terms of the integrity of the composition, the additional constructs constitute a further precondition for the transitions of the WF-net. That way, although the added transitions extend the language of the initial WF-net, the order of execution is supposed to be preserved. A closer look at this aspect will be taken in the course of a language decomposition.

Besides safeness, there are further properties of the user-task encoding, which are easy to ascertain based on the provided behavioral and structural definitions related to Petri nets. Each user-task authorization construct for a WF-task (i.e., the parts in Figure 3.25a where the labeling begins with *u* ...) represents a **state machine** (which implies FC) because each transition has exactly one input place

**Figure 3.27** Basic choice net for different user assignments for a single task *t*

**Figure 3.28** Choice net with complement-place *pt*+ and -arcs

and one output place. An authorization construct is **plain** (all arc weights are 1) and **pure** (no self-loops), **well-handled** (there are no PT/TP handles for any of the resulting PT or TP pairs). Moreover, the choice construct implies that each transition is enabled for some marking (simply live). Since the encoding introduces further input (or source) places, the overall net is not a WF-net anymore.

#### **3.2.3.2 Net Properties of Modeled Constraints**

The modeling of SoD and BoD constraints share the same modeling principle. They both introduce choice places (positioned in the upper area in Figure 3.25 and Figure 3.26) to model mutual exclusion in some way. Therefore, the properties of these nets will be subsumed under the notion of constraint nets.

Analogously to the intention of safeness in the user-task constructs, the choice place that is used for the modeling of constraints indicates whether the constraint affects the user-task assignment or not. Accordingly, the meaning of multiple tokens in such an SoD or BoD place would be unclear as well. For example, two tokens in such a place would directly represent an error, i.e., they would violate the intended constraint since both transitions affected by the choice place would then be fireable, and that way they circumvent the mutual exclusion of the two conflicting transitions. Hence, constraint modeling constructs are supposed to be safe as well. The safeness of the constraint constructs, i.e., a marked choice place connected to several usertask transitions, directly results from the fact that these arcs only consume tokens. Hence, the marking of the initially marked place may not increase. The safeness of constraint constructs connected to some user-task-related constructs results from this observation as well. The modeling of constraints only uses arcs that consume tokens from choice places. They represent a further condition for the affected usertask-transitions to fire. Hence, the overall number of produced tokens does not increase due to the modeling of constraints, i.e., the net construct remains safe.

However, with the introduction of places that connect multiple initially freechoice authorization constructs, the overall regarded construct modeling the policy is not free-choice anymore. Indeed, structurally, some rather simple constructs may model an asymmetric choice, for example, if one considers the BoD place *pBoDu*1*<sup>t</sup>* 1 and the affected user-task construct from Figure 3.26 in isolation. However, each user-task construct affected by a constraint usually then depends on some further places influenced by the firing of transitions beyond the scope of the transitions within a single user-task construct, i.e., they are not free-choice. For instance, the firing of*tu*1*t*<sup>2</sup> in the SecANet example reduces the choice between the transitions*tu*1*t*<sup>1</sup> and *tu*2*t*<sup>1</sup> . Hence, the FC-property that, if any output transition of the place *pt*− is enabled, all output transitions of that place are enabled, does not hold. Apart from the structural downside, this, is nevertheless just in line with the desired interpretation of the encoded policy elements. Given that there are SoD or BoD constraints, the choice between the users that can be assigned to a task is not free anymore but depends on whether the users are involved in other tasks as well.

Further, since the connection with the WF-net finally allows drawing two simple paths from the constraint place to a respective transition in the WF-net (PT-Handle), the overall net is not well-handled anymore. Although important properties for an efficient computation are remained, e.g., the overall net still represents a safe P/T net, the effect of this modeling on complexity will be considered in the evaluation of the approach. For instance, as indicated before, there are ways to make this construct hold the free-choice property again, whereby, the structural complexity increases to some extent though.

In terms of the integrity of inputs, the constraints are applied to the specific user-task authorizations. Hence, they do not directly allow following and tracing the policy in an explicit way as it was possible in the modeling of the authorization policy with explicit user-task transitions. Rather, it is the case that they manifest themselves in what is not allowed, thereby restricting the possibilities given by the user-task assignment. However, based on the given choice-place, it is at least traceable which constraint has had an impact on the execution. For example, because an SoD place denotes the user and its two conflicting tasks, an empty SoD place encodes that the constraint is in force for the two conflicting user-task assignments. In connection with the fired user-task assignment transition, it is further traceable, which of the users has been assigned to which activity, thereby adhering to the constraint. Hence, the presence or absence of a token in an SoD place traces if the SoD constraint is applied or not. The name of the SoD constraint and its arcs allow retracing tasks affected by it. The user-task assignment itself is then a result of the applied SoD constraint. In this way, the encoding of the SoD constraint preserves its intended behavior.

In terms of the integrity of the overall composition, the impact that results from constraint modeling is observed. Because the constraint restricts given allowed states, what is not allowed can be depicted by comparing the constrained allowed states with what would be allowed if the constraint was not there. With each choice place, the corresponding user task transition is limited, such that the firing sequences reflect the constraint behavior. A closer look at these aspects will be taken in the course of the language-related examination.

#### **3.2.4 Language-Based SecANet Properties**

The observation of the full firing sequences of the example SecANet shows that, whereas the authorization policy provides different possibilities to assign users to tasks, constraints restrict these possibilities. In particular, constraints do not add new behavior. Rather, they determine which of the full firing sequences given by the usertask assignment are not allowed anymore. So far, it has seemed that the encoding of authorizations preserves the integrity of the overall representation. It appears that this is also the case for the encoding of constraints. The following examination of language-related properties will deepen these considerations, in particular for proving the behavioral integrity of the SecANet approach.

For this, formal details on the language of Petri nets and useful language-related operators will be introduced first. The SecANet will then be broken down into its smaller increments and reassembled again. This will allow to reason on languagerelated properties on different subnet levels and to finally determine the overall SecANet language.

#### **3.2.4.1 Language-Related Operators and Nets**

The theory of formal languages provides a large number of operations on languages, some of which will be briefly introduced here. The subsequent language-related Petri net definitions were adapted from Priese and Wimmel [167].

To begin with, an alphabet of a language is usually a finite, non-empty set.

**Definition 3.35 (Word and Language).** *A word* w*over an alphabet consists of a finite (possibly empty) sequence of letters from . The empty word is denoted by .* |w| *denotes the number of letters in* w*,* w(*i*) *for* 1 ≤ *i* ≤ |w| *stands for the i -th letter of the word* w*. Furthermore,* #*a*(w) *is the number of occurrences of the letter a* ∈ *in the word* w*. A language over is a set of words over . The set of all words over is denoted by* ∗*; the empty language by* ∅*. For a language L, the alphabet <sup>L</sup>* := {*a*|∃w ∈ *L*∃*i* ∈ {1,..., |w|} : w(*i*) = *a*} *denotes the (minimal) alphabet, which consists of all letters that actually occur in at least one word of L. Therefore, for L* ⊆ ∗, *<sup>L</sup>* <sup>⊆</sup> *holds. The Parikh image P*(w) *of a word* <sup>w</sup> <sup>∈</sup> <sup>∗</sup> *is the vector in* <sup>N</sup> *with P*(w)(*a*) := #*a*(w) *for a* <sup>∈</sup> *. The mapping P :* <sup>∗</sup> <sup>→</sup> <sup>N</sup> with *<sup>P</sup>*(w) *as the Parikh image of* w *is also called "Parikh mapping". The set of all prefixes of a word* w ∈ <sup>∗</sup> *is defined as* Prew := {v<sup>1</sup> ∈ ∗|∃v<sup>2</sup> ∈ <sup>∗</sup> : v1v<sup>2</sup> = w}*.*

A language containing only the empty word, i.e., *L* = { }, has the alphabet *<sup>L</sup>* = ∅. Thus, by definition, this *L* is not an alphabet at all. For the sake of simplicity, this case is also referred to as the minimal "alphabet" *<sup>L</sup>* for *L*.

**Definition 3.36 (Language Operations).** *Let L*<sup>1</sup> *and L*<sup>2</sup> *be languages of an alphabet . The following operations are defined:*


<sup>8</sup> The restriction of a language must not be confused with the restriction for two languages, for which a special operator will subsequently be introduced as well.

Moreover, in order to label the Petri net transitions with letters, the definition of a homomorphism will be used.

**Definition 3.37 (Homomorphism).** *Given that* and *are alphabets and h is a map h :* → ∗*, the homomorphism h*ˆ : <sup>∗</sup> → <sup>∗</sup> *is inductively given by h*ˆ( ) := *and for* w1, w<sup>2</sup> ∈ <sup>∗</sup>*: h*ˆ(w1w2) := *h*ˆ(w1) · *h*ˆ(w2)*. Usually, there is no distinction between h* and *h. For a language L* ˆ <sup>1</sup> ⊆ , *h*(*L*1) *is defined as h*(*L*1) := {*h*(w)|w ∈ *L*1}*.*


A language operator that is particularly interesting for Petri nets is the shuffle operator. It builds a link to reflect the concurrent nature of Petri nets in the sequential nature of word sequences determining a language. It can be visualized by "sticking" two stacks of playing cards together while shuffling. The single cards stand for letters and the two stacks represent two words.

**Definition 3.38 (Shuffle (**-**)).** *The shuffle for two words* w<sup>1</sup> w2, w1, w<sup>2</sup> ∈ <sup>∗</sup> *is defined as* w1- := {w1}*,* <sup>w</sup><sup>2</sup> := {w2}, <sup>∀</sup>*a*, *<sup>b</sup>* <sup>∈</sup> : <sup>w</sup>1*a*w2*b* := (w1*a*<sup>w</sup>2)*b*∪(w1w2*b*)*a. The shuffle is canonically extended to languages <sup>L</sup>*1, *<sup>L</sup>*<sup>2</sup> <sup>⊆</sup> <sup>∗</sup> as *<sup>L</sup>*<sup>1</sup> - *<sup>L</sup>*<sup>2</sup> := - w1∈*L*1,w2∈*L*<sup>2</sup> w<sup>1</sup> w2*.*

For example, for the two languages {*ab*, *ad*} and {*ef* } is

{*ab*, *ad*} - {*ef* }={*abef* , *aebf* , *aef b*, *eabf* , *eaf b*, *ef ab*, *adef* , *aed f* , *aef d*, *ead f* , *eaf d*, *ef ad*}.

The shuffled words are thus composed of one word from each of the languages involved. While the letters of the same word remain in the given order, the letters of different words in the shuffle can appear in any order. There are no causal dependencies between these words. In this sense, the shuffle reflects concurrency that is not directly recognizable in a target word. If the inherently concurrent behavior of Petri nets is modeled using shuffle, one also speaks of interleaving models. Moreover, the shuffle operator now allows the definition of the restriction of two languages.

**Definition 3.39 (Restriction Operator (** - **)).** *The restriction operator* - *for two languages L*<sup>1</sup> *and L*<sup>2</sup> *is defined over (the minimally selected) alphabets L*<sup>1</sup> *and L*<sup>2</sup> *as L*1-*<sup>L</sup>*<sup>2</sup> := (*L*<sup>1</sup> - (*L*<sup>2</sup> <sup>−</sup> *L*<sup>1</sup> )∗) <sup>∩</sup> (*L*<sup>2</sup> - (*L*<sup>1</sup> − *L*<sup>2</sup> )∗)

In order to assign a language to a Petri net, it is extended with a mapping that assigns a letter to be generated to each transition. Firing a sequence of transitions creates a word. In this case, the transition system of the marking graph determines the language. In order to increase the expressive power of Petri nets, or, their languages, respectively, final states are often assigned to Petri nets, such that the word belonging to a firing sequence lies in the language of the net only if one of the final markings can be reached at the end of the firing sequence. Because the focus of obstructability lies on process completion, a language-generating Petri net is supposed to consider final markings as well. Moreover, a letter assigned to a transition may also be the empty word , or the same letter is assigned to multiple transitions. Hence, the labeling of a Petri net may be free (i.e., an identity homomorphism), -free (i.e., a very fine homomorphism), or arbitrary (i.e., a fine homomorphism, such that multiple transitions may have the same letter assigned to them).

**Definition 3.40 (Language-Generating Petri Net).** *A language-generating Petri Net N is a 7-tuple N* = -*P*, *T* , *F*, *m*0, *M <sup>f</sup>* ,, *h , consisting of a Petri net* -*P*, *T* , *F*, *m*0 *with an initial marking m*0*, a finite set of final markings M <sup>f</sup>* <sup>⊆</sup> <sup>N</sup>*P, an alphabet and a labeling h : T* <sup>→</sup> ∪ { }*. h is continued on T* <sup>∗</sup>*, by defining h*( ) = and *h*(σ1σ2) = *h*(σ1)*h*(σ2)*, such that h is then a homomorphism.*

*Every Petri Net N* = -*P*, *T* , *F*, *m*0 *is canonically identified with the language-generating Petri Net* -*P*, *T* , *F*, *m*0, ∅, *T* ,*id, where the labeling* *function is the identity. From now on, the word "language-generating" will be omitted as it is always clear what is meant in each case.*

*The labeling* τ *is identified for transitions with the empty word . Thus, h can be extended to a homomorphism in the usual way h* : *T* <sup>∗</sup> → ∗: *h*( ) := ,

$$\begin{array}{rcl} h\_{\ell}(t) := \begin{cases} t, & \text{if } t \in \Sigma - \{\pi\} \\ \epsilon, & \text{if } t = \pi \\ h\_{\ell}(\sigma t) := h\_{\ell}(\sigma) h\_{\ell}(t) \end{cases} \end{array}$$

*A Petri net N* = -*P*, *T* , *F*, *m*0, *M <sup>f</sup>* ,, *h in which h*(*t*) = *for all t* ∈ *T is called* " *-free*"*. The net N wherein* = *T and h*(*t*) = *t for all t* ∈ *T is called "free". For an arbitrary Petri net N* = -*P*, *T* , *F*, *m*0, *M <sup>f</sup>* ,, *h*, *<sup>N</sup> <sup>f</sup>* = -*P*, *T* , *F*, *m*0, *M <sup>f</sup>* , *T* ,*id is the free version of N*.

τ is just another name for the empty word . In Petri net theory, τ has become customary. One notion is that transitions labeled with τ are supposed to be invisible to an observer of a Petri net. The symbol λ can often be found for τ as well. In case that Petri nets are used to model business processes, it is not unusual to distinguish between so-called regular transitions (i.e., *t* labeled with some letter in − {τ }) and silent transitions (i.e., *t* labeled with τ ). Silent transitions do not represent the execution of a process activity and are used for routing purposes or to achieve a more compact representation of the net. That way, for example, optional process activities can be modeled as a choice between a silent transition and the process activity itself. Moreover, silent transitions may also be introduced in case that a net is transformed in order to obtain desirable net properties. For example, if an arbitrary net is transformed into a free-choice net, it may be describable that the transitions added in the course of the free-choice transformation are silent as well. Silent transitions are not considered in the language determined by (completed) firing sequences.

Based on such a (somehow) labeled Petri net, the set of all possible firing sequences resulting from the execution that starts in an initial marking and terminates in some final marking determines a language. The term "final" must indeed be considered in a more differentiated way: Whereas arbitrary markings can be defined as final markings, the notion of "terminal" markings describes markings given by all states that do not allow the firing of any further transition, namely deadlock markings.

Based on these considerations, the study of Petri nets in formal language theory has introduced several notions of Petri net languages. The standard notion of a Petri net language accepts sequences of transition labels in a run from an initial to a final marking. The prefix language considers all markings to be final. Here, each prefix of a word is itself a word of the language. The covering language accepts sequences leading to markings that are greater or equal to a given set of final markings. Finally, the terminal languages only accept sequences leading to a deadlock [160, 161]:

**Definition 3.41 (Petri Net Language).** *Let N* = -*P*, *T* , *F*, *m*0, *M <sup>f</sup>* ,, *h be a Petri net.*

*The language of N accepts firing sequences to the final marking, i.e., the set of final markings is defined by a finite marking set. It is defined as L*(*N*) = {w ∈ ∗|∃σ ∈ *T* <sup>∗</sup> ∃*m <sup>f</sup>* ∈ *M <sup>f</sup>* : *m*0[σ*m <sup>f</sup>* ∧ *h*(σ ) = w}*.*

*The prefix language of N accepts all transition sequences (in other words, all reachable markings are final markings) and is defined as P*(*N*) = {w ∈ ∗|∃σ ∈ *T* <sup>∗</sup> : *m*0[σ ∧ *h*(σ ) = w}.

*The covering language of N accepts all transition sequences reaching a marking that is greater than or equal to any element of the set of final markings. It is defined as C*(*N*) = {<sup>w</sup> <sup>∈</sup> ∗|∃<sup>σ</sup> <sup>∈</sup> *<sup>T</sup>* <sup>∗</sup> <sup>∃</sup>*<sup>m</sup> <sup>f</sup>* <sup>∈</sup> *<sup>M</sup> <sup>f</sup>* <sup>∃</sup>*<sup>m</sup>* <sup>∈</sup> <sup>N</sup>*P: m*0[σ*m* ∧ *m* ≥ *m <sup>f</sup>* ∧ *h*(σ ) = w}*.*

*The terminal language N accepts runs to deadlock markings, such that the set of final markings results from any terminal marking (a marking in which no transition is enabled). The terminal language is defined as <sup>T</sup>* (*N*) = {<sup>w</sup> <sup>∈</sup> ∗|∃<sup>σ</sup> <sup>∈</sup> *<sup>T</sup>* <sup>∗</sup> <sup>∃</sup>*<sup>m</sup>* <sup>∈</sup> <sup>N</sup>*<sup>P</sup>* : *<sup>m</sup>*0[σ*<sup>m</sup>* <sup>∧</sup> *<sup>h</sup>*(σ ) <sup>=</sup> <sup>w</sup> <sup>∧</sup> *t* ∈ *T* : *m*[*t*}*.*

Petri net languages represent the interleaving semantic of Petri nets. As indicated before, Petri net languages can model the inherently concurrent behavior of Petri nets with the help of the shuffle operator. It is assumed, however, that narrowing down the view from true concurrency to interleaving behavior is not significant for the consideration of business process activities in the context of this thesis. Indeed, it is unlikely and irrelevant whether parallel tasks will take place at exactly the same time such that they happen in one step (true concurrency). Rather, the point is that parallel tasks in business processes (or parallel user-task assignments) can be executed independently from each other.

Hence, the three different labeling functions and the four different language types result in twelve different language classes. The focus of this work can be limited to non-prefix-closed languages of predominantly free nets. Hence, the prefix type and the terminal type (which is non-prefix-closed) do not require the definition of a final marking. P-type languages represent the sequence semantics, i.e. each possible fire sequence corresponds to one word of the language of the net. T-type languages stand for the complete sequence semantics, which reduces the language of the net to those words that are created by completed terminal firing sequences. However, both languages can be represented with the help of final markings as well. On the one hand, the prefix language *P*(*N*) can be expressed as the covering language of the marking that assigns zero to all places, i.e., *P*(*P*, *T* , *F*, *m*0, ∅,, *h*) = *C*(*P*, *T* , *F*, *m*0, **0**,, *h*), or equivalently, *C*(*P*, *T* , *F*, *m*0, ∅,, *h*). That way, the prefix-closure could also be reproduced by defining each reachable marking as a final state of the language *L* = *C*(*P*, *T* , *F*, *m*0,[*m*0,, *h*) . On the other hand, the terminal language *T* (*N*) can be represented as the language *L* of the set of final markings that contains all terminal markings, that is, *T* (*P*, *T* , *F*, *m*0, ∅,, *h*) = *L*(*P*, *T* , *F*, *m*0,[*m*0*<sup>T</sup>* ,, *h*).

**Figure 3.29** Determine Market Value workflow as WF-net with initial marking

These different perspectives are also underlined by observing the different languages of the basic WF-net of the DMV example from Figure 3.29, i.e., *N* = -*P*, *T* , *F*, *m*0, *M <sup>f</sup>* , *T* ,*id* where *M <sup>f</sup>* = {{*po*}}, = {*t*1, *t*2}, and *h*(*t*1) = *t*1, *h*(*t*2) = *t*2. Here, *L*(*N*) = *C*(*N*) = *T* (*N*) = {*t*<sup>1</sup> ·*t*2} and *P*(*N*) = {∅, *t*1, *t*<sup>1</sup> ·*t*2} = *Pre L*(*N*). For a different final marking *M <sup>f</sup>* = {{*p*2}} only the L- and C-type languages change, namely *L*(*N*) = {*t*1} and*C*(*N*) = {*t*1, *t*<sup>1</sup> ·*t*2}. In this regard, Peterson has already recognized that the language types L and T are equally expressive, that is, for every net N, there is a net *N* with *L*(*N*) = *T* (*N* ) and vice versa. The types P and C have less expressive power [161].

#### **3.2.4.2 SecANet Language Types**

Based on these language-related definitions, the language of a SecANet will now be examined. First of all, in order to investigate language related properties, a labeling function will assign an alphabet to the transitions of the SecANet. Because the SecANet definitions encode each transition distinctively, the labeling function represents the identity function. Hence, the labeling of a SecANet is free, that means, there are no arbitrary labelings or -labelings. That way, the language types can be directly related to the set of full and terminal, obstructed and satisfiable firing sequences of a SecANet:


In order to obtain an expressive SecANet language that is able to encode satisfiable but also obstructed firing sequences, its language-type is supposed to contain words that reach final markings that are terminal. Because satisfiable words can contain prefixes that are already satisfiable (i.e., words of the covering language), this means no loss of generality, i.e., the terminal words encode all relevant firing sequences. Based on these considerations, the subsequent language observations assume T-type languages. Because L-type languages are able to express all different languagetypes with a corresponding set of final markings, the terminal SecANet language *T* (SecANet) is equal to the SecANet language *L*(SecANet) with the finite marking set [*m*0*<sup>T</sup>* . Hence, the language-generating SecANet that is subsequently considered is a free Petri net of the form *N* = -*P*, *T* , *F*, *m*0,[*m*0*<sup>T</sup>* , *T* ,*idT* .

However, determining the language of a SecANet already appears to be difficult for the supposedly simple example of the DMV SecANet in Figure 3.25. Thus, to determine the language of a SecANet, further operations that allow to decompose the net such that the language of smaller parts of the net can actually be determined are required. These parts of the language can then be combined again in a further step, whereby the language of the entire net can be determined. In the following, this decomposition and composition will first be illustrated by determining the language of the example SecANet.

#### **3.2.4.3 Decomposition**

To obtain the language of a particular Petri net, it will first be decomposed into smaller subnets whose languages are straightforwardly determinable. To do this, the subnet are constructed by a selection of disjoint subsets of places. The place subsets together with their incoming and outgoing transitions will constitute the elements of the resulting subnets. Their initial and final markings will be determined based on the markings of the initial net. If the subnets are small enough, their languages can then be determined easily.

As a preparation for the subsequent definition of a subnet, projections will be useful in order to obtain the initial and final markings of the subnets. They are denoted by <sup>π</sup>. For a set *<sup>P</sup>*, <sup>N</sup>*<sup>P</sup>* stands for the set of all mappings *<sup>f</sup>* : *<sup>P</sup>* <sup>→</sup> <sup>N</sup>. For finite sets *<sup>P</sup>* = {*p*1,..., *pn*}, <sup>N</sup>*<sup>P</sup>* can be identified with <sup>N</sup>|*P*<sup>|</sup> , which denotes the set of all <sup>|</sup>*P*|-dimensional column vectors over <sup>N</sup>. If *<sup>p</sup>* is a distinguished element in *<sup>P</sup>* and *<sup>P</sup>* <sup>⊆</sup> *<sup>P</sup>* = {*p*1,..., *pn*} is a distinguished subset of *<sup>P</sup>*, then <sup>π</sup>*<sup>p</sup>* : <sup>N</sup>*<sup>P</sup>* <sup>→</sup> <sup>N</sup> and <sup>π</sup>*<sup>p</sup>* : <sup>N</sup>*<sup>P</sup>* <sup>→</sup> <sup>N</sup>*<sup>P</sup>* are the projections with π*p*(v) = v(*p*) and π*<sup>P</sup>* (v) = (v(*pi*<sup>1</sup> ), . . . , v(*pik* ))<sup>9</sup> for a vector <sup>v</sup> and *<sup>P</sup>* = {*pi*<sup>1</sup> ,..., *pik* } with *<sup>i</sup>*<sup>1</sup> <...< *ik* . A vector <sup>v</sup> <sup>∈</sup> <sup>N</sup>*<sup>P</sup>* is understood as an element of <sup>N</sup>*<sup>P</sup>* with v(*p*) <sup>=</sup> 0 for all *<sup>p</sup>* <sup>∈</sup> *<sup>P</sup>* <sup>−</sup> *<sup>P</sup>* , which describes the canonical embedding of N*<sup>P</sup>* in N*P*.

**Definition 3.42 (Subnet).** *Given a Petri net N* = -*P*, *T* , *F*, *m*0, *M <sup>f</sup>* ,, *h and P* ⊆ *P, the following can be defined:*

$$
\pi\_{0,P'} := \pi\_{P'}(m\_0), \ M\_{f,P'} := \pi\_{P'}(M\_f).
$$

<sup>9</sup> represents the transpose and allows a row-based notation of the column vector.

*The subnet generated by P is defined as N*(*P* ) := -*P* , *T* , *F*|(*<sup>P</sup>* ×*T* )∪(*T* ×*P* ),*m*0,*<sup>P</sup>* ,, *h*|*<sup>T</sup>* , *M <sup>f</sup>* ,*P , where T* := • *P* ∪ *P*•*. For P* ⊆ *P with N* = *N*(*P* )*, N represents a so-called "closed" subnet of N. Additionally, a net with* |*P* | = 1 *is called "elementary".*

Whereas, in the course of the flattening, all inputs were integrated into the WF-net step by step, for a decomposition, it will be necessary to decompose the elements of the flattened net into smaller tuples or subsets. Therefore, a dot-notation, which is supposed to unambiguously indicate which specific set or tuple is regarded, will be introduced for better clarity.

**Definition 3.43 (Dot-Notation).** *Let Q be some set and s a description of some subset of Q. The dotted-set notation Q*˙ *<sup>s</sup> determines the subset of Q consisting only of the elements described with the subscripted s. The dotnotation is canonically extended for tuples such that for some tuple Y* = -*Q*1, *Q*<sup>2</sup> ..., *Qn, the dot-notation is continued onto its elements, i.e., Y*˙ *s* = -*Q*˙ <sup>1</sup>*<sup>s</sup>* , *Q*˙ <sup>2</sup>*<sup>s</sup>* ..., *Q*˙ *ns .*

For the example SecANet, the dotted *P*˙ *T A*+*SoD* thus determines that this set does only contain the subscripted net elements, e.g., in this case, only *T A* + *SoD* places from user-task or SoD-constraint modeling without WF-net places, i.e., *P*˙ *T A*+*SoD* = *PT A*+*SoD* − *P* = {*pt*1−, *pt*1+, *pt*2−, *pt*2+, *SoDu*1*t*1*t*<sup>2</sup> }.

**Decomposition of the Example SecANet:** The decomposition of a free Petri net into subnets is demonstrated by means of the SecANet example depicted in Figure 3.23b. First, the set of places is divided into two disjoint subsets *P* = {*pi*, *p*2, *po*} and *P*˙ *T A*+*SoD* = {*pt*1−, *pt*1+, *pt*2−, *pt*2+, *SoDu*1*t*1*t*<sup>2</sup> }. The closed subnets *N* = *N*(*P*) and *N*˙ *T A*+*SoD* = *N*(*P*˙ *T A*+*SoD*) are illustrated in Figure 3.30. The initial marking of the two subnets *N* and *N*˙ *T A*+*SoD* is *m*0,*<sup>P</sup>* = {*pi*} and *m*0,*P*˙ *T A*+*SoD* = {*pt*1−, *pt*2−, *SoDu*1*t*1*t*<sup>2</sup> }. Because the final markings for the example nets result from the terminal markings of the SecANet *M <sup>f</sup>* = [*m*0*<sup>T</sup>* = {{*po*},{*p*2, *pt*2−}}, the projection of this marking onto the subnets *N*(*P*) and

**Figure 3.30** Example decomposition of the SecANet example

*NT A*+*SoD* is *M <sup>f</sup>* ,*<sup>P</sup>* = {{*po*},{*p*2}}, and *M <sup>f</sup>* ,*P*˙ *T A*+*SoD* = {∅,{*pt*2−}}, respectively. The language generated by the subnet *N* = {*P*, *T* , *F*, *m*0, *M <sup>f</sup>* ,*P*, *T* ,*idT* } and its alphabet is now easy to determine, namely

$$\begin{aligned} L(N) &= \mathbf{x} & \quad \{t\_1 \ t\_2, t\_1\} \text{ and } \\ \Sigma\_N &= \mathbf{x} & \quad \{t\_1, t\_2\} \text{ and } \end{aligned}$$

In order to determine the language of the other subnet *L*(*N*˙ *T A*+*SoD*), a further decomposition is necessary. The set of places of *N*˙ *T A*+*SoD* is divided into two disjoint subsets *P*˙ *T A* = {*pt*1−, *pt*1+, *pt*2−, *pt*2+} and *P*˙ *SoD* = {*SoDu*1*t*1*t*<sup>2</sup> }. That way, the closed subnets *N*˙ *T A* = *N*(*P*˙ *T A*) and *N*˙ *SoD* = *N*(*P*˙ *SoD*) are obtained, as illustrated in Figure 3.31. The projection of the final markings of the subnet *N*(*P*˙ *T A*+*SoD*), namely *M <sup>f</sup>* ,*P*˙ *T A*+*SoD* = {∅,{*pt*2−}}, onto the subnets *<sup>N</sup>*(*P*˙ *T A*), and *N*(*P*˙ *SoD*) is *M <sup>f</sup>* ,*P*˙ *T A* = {∅,{*pt*2−}} and *M <sup>f</sup>* ,*P*˙ *SoD* = {∅}, respectively. The languages and alphabets generated by *N*˙ *T A* and *N*˙ *SoD* are

$$\begin{aligned} L(\dot{N}\_{TA}) &= \{ (t\_{u\_2t\_1} \cup t\_{u\_1t\_1}) \mid t\_1 \sqcup t\_{u\_1t\_2} \ t\_2, t\_{u\_1t\_1} \ t\_1 \} \text{ with} \\ \Sigma\_{TA} &= \{ t\_{u\_1t\_1}, t\_{u\_2t\_1}, t\_{u\_1t\_2}, t\_1, t\_2 \}, \text{and} \\ (\dot{N}\_{SoD}) &= \{ \begin{array}{l} (t\_{u\_1t\_1} \cup t\_{u\_1t\_2}) \text{ with} \\ \{t\_{u\_1t\_1}, t\_{u\_1t\_2}\}, \text{respectively} \end{array} \} \end{aligned}$$

**Figure 3.31** Example decomposition of *NT A*+*SoD*

Note that, (*tu*1*t*<sup>1</sup> ∪ *tu*1*t*<sup>2</sup> ), for example, represents the union of two disjoint sets (or symmetric difference) and stands for the logical exclusive-or (XOR) for sets. It results in the SoD subnet language {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }, which, thus, directly encodes the exclusive choice between two conflicting user-task transitions.

#### **3.2.4.4 Composition**

Based on the decomposition, it can now be considered how to determine the language of a free Petri net if the languages of its subnets are known. Apparently, in order to assemble the subnets, transitions that occur in several subnets must be "merged" in some way. This points to the use of a further operation in the theory of formal languages, namely synchronization. Indeed, a couple of operations such as intersection, shuffle and restriction are simple special cases of synchronization, and synchronization is a quite natural operation for Petri nets. Unfortunately, as a language operation, it is all the more complicated [167]:

**Definition 3.44 (Synchronization of Languages).** *Let* Σ1, Σ<sup>2</sup> *be two alphabets,* Σ *a finite set and L*<sup>1</sup> ⊆ Σ<sup>∗</sup> <sup>1</sup> *and L*<sup>2</sup> ⊆ Σ<sup>∗</sup> <sup>2</sup> *two languages. The* Σ*-Synchronization L*<sup>1</sup> *sy*<sup>Σ</sup> *L*<sup>2</sup> *of L*<sup>1</sup> *and L*<sup>2</sup> *is defined by*

$$L\_1 \text{ sy}\_{\Sigma} L\_2 := \text{g} \left( \left( h(L\_1) \sqcup (\Sigma\_2 - \Sigma)^\* \right) \cap \left( L\_2 \sqcup h((\Sigma\_1 - \Sigma)^\*) \right) \right),$$

*where h:* Σ∗ <sup>1</sup> → (Σ <sup>1</sup> ∪ Σ)<sup>∗</sup> *is the labeling with h*(*a*) := *a for a* ∈ Σ *and h*(*a*) := *a for a* ∈ Σ<sup>1</sup> − Σ*, where* Σ <sup>1</sup> *is the alphabet* Σ <sup>1</sup> := {*a* |*a* ∈ Σ1}*,* *and g* : (Σ<sup>2</sup> ∪(Σ<sup>1</sup> −Σ))<sup>∗</sup> → (Σ1∪Σ<sup>2</sup> ∪Σ)<sup>∗</sup> *is the labeling with g*(*a* ) := *a for a* ∈ Σ <sup>1</sup> *and g*(*a*) := *a for a* ∈ Σ2*.* Σ *can also be denoted as the synchronization alphabet and may—in contrast to usual alphabets—also be empty.*

Note that, for an empty synchronization alphabet, it is directly apparent that

$$\begin{aligned} L\_1 \text{syo}\_{\emptyset} L\_2 &= \text{g} \left( \left( h(L\_1) \Sigma\_2^\* \right) \cap \left( L\_2 \Sigma^{\*^\*} \right) \right), \\ &= L\_1 \sqcup L\_2. \end{aligned}$$

Because the the restriction is just defined as *L*1-*L*<sup>2</sup> = (*L*1(2−1)∗)∩(*L*2(1− 2)∗)) according to Definition 3.39, this means that:

$$\begin{split} L\_{1^{S}\chi\Sigma\_{1}\cap\Sigma\_{2}}L\_{2} &= & \operatorname{g} \big( (h(L\_{1})\sqcup(\Sigma\_{2}-(\Sigma\_{1}\cap\Sigma\_{2}))^{\*} \\ &\quad \cap \big( L\_{2}\sqcup h(\Sigma\_{1}-(\Sigma\_{1}\cap\Sigma\_{2}))^{\*} \big) \\ &= & \operatorname{g} \big( (h(L\_{1})\sqcup(\Sigma\_{2}-\Sigma\_{1})^{\*})\big( (L\_{2}\sqcup h(\Sigma\_{1}-\Sigma\_{2})^{\*} \big) \big) \\ &\overset{(\*)}{=} & (L\_{1}\sqcup(\Sigma\_{2}-\Sigma\_{1})^{\*})\big( (L\_{2}\sqcup(\Sigma\_{1}-\Sigma\_{2})^{\*} \big) \\ &= & L\_{1}\oplus L\_{2} .\end{split}$$

(∗) can be observed straightforwardly because *h* renames the letters in <sup>2</sup> − 1, i.e., exactly those letters that do not exist in *L*<sup>2</sup> anyway. So *h* and *g* can also be dropped [167].

The synchronization of languages can canonically be extended to Petri nets. It stands for the counterpart of the decomposition into subnets and allows to combine nets and other languages. While subnets are determined by means of a selection of a set of disjoint places, the synchronization of nets aims at combining transitions labeled identically. The definition of the synchronization of nets by Priese and Wimmel [167] will subsequently be adapted to the definitions provided in this thesis.

**Definition 3.45 (Synchronization of Nets).** *Let Ni* = -*Pi*, *Ti*, *Fi*, *moi*, *M <sup>f</sup>* ,*i*, Σ*i*, *h <sup>i</sup> for i* ∈ {1, 2} *be two Petri nets and* Σ *a (possibly empty) synchronization alphabet* (τ /∈ Σ)*. Without losing* *generality, it is assumed that the nets are disjoint. The* Σ*-Synchronization of the nets N*<sup>1</sup> *and N*<sup>2</sup> *is defined as N*<sup>1</sup> *sy*<sup>Σ</sup> *N*<sup>2</sup> :=(*P*1∪˙ *P*2, *T*ˆ <sup>1</sup> ∪ *T* <sup>×</sup> ∪ *T*ˆ <sup>2</sup>, *F*ˆ<sup>1</sup> ∪ *F*<sup>×</sup> ∪ *F*ˆ2, (*m*1, *m*2), Σ<sup>1</sup> ∪Σ2, *h*, *M <sup>f</sup>* ,<sup>1</sup> × *M <sup>f</sup>* ,2*) with the following components: T*ˆ *<sup>i</sup>* := {*t* ∈ *Ti*|*h <sup>i</sup>*(*t*) /∈ Σ} *for i* ∈ {1, 2}, *T* <sup>×</sup> :={(*t*1, *t*2) ∈ *T*<sup>1</sup> × *T*<sup>2</sup> | *h* <sup>1</sup>(*t*1) = *h* <sup>2</sup>(*t*2) ∈ Σ}, *F*ˆ*<sup>i</sup>* = *F<sup>i</sup>* − {*t*, *p*,*p*, *t* ∈ *Fi*|*t* ∈ *Ti* ∧ *h <sup>i</sup>*(*t*) ∈ }, *F*<sup>×</sup> = {-(*t*1, *t*2), *p*|(*t*1, *t*2) ∈ *T* <sup>×</sup> ∧ (*t*1, *p* ∈ *F*<sup>1</sup> ∨ *t*2, *p* ∈ *F*2)} ∪ {*p*, (*t*1, *t*2)|(*t*1, *t*2) ∈ *T* <sup>×</sup> ∧ (*p*, *t*1 ∈ *F*<sup>1</sup> ∨ *p*, *t*2 ∈ *F*2)}.

Figure 3.32 depicts the -synchronization of *N*˙ *T A* and *N*˙ *SoD* of the example net with the synchronization alphabet = {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }. It illustrates how the synchronization takes place via the transitions whose labels lie within the synchronization alphabet Σ. Each single transition of two nets *N*<sup>1</sup> and *N*<sup>2</sup> with the same labeling of Σ is combined (or "merged") with each other, including its former pre- and post-areas. The resulting transitions are in *T* ×. All other transitions and places are simply transferred to the new net. Note that *L*(*N*1)*sy L*(*N*2) = *L*(*N*1*sy N*2) [167].

For the synchronization of two subnets *N*(*P*1) and *N*(*P*2) resulting from the decomposition of a free Petri net (without isolated transitions) *N* = -*P*, *T* , *F*, *m*0, *M <sup>f</sup>* , *T* ,*id* with *P*1∩ *P*<sup>2</sup> = ∅ and *P*1∪ *P*<sup>2</sup> = *P* , and the synchronization alphabet representing the common transitions of the two subnets = *TN*(*P*1)∩*TN*(*P*2), the following applies (for a detailed proof see Priese et al. [167]): If the final state set of N

**Figure 3.32** *N*˙ *T Asy*{*tu*1*<sup>t</sup>* <sup>1</sup> ,*tu*1*<sup>t</sup>* <sup>2</sup> }*N*˙ *SoD* (transitions with a label from the synchronization alphabet are synchronized, all other transitions are simply taken over)

is just the product of the two final state sets of the subnets, i.e., *M <sup>f</sup>* = *M <sup>f</sup>* ,<sup>1</sup> × *M <sup>f</sup>* ,2, the synchronization of the two subnets just constitutes the original net again, i.e., *N* = *N*(*P*1)*sy N*(*P*2). Then, the synchronization *N*(*P*1)*sy N*(*P*2) is identical to *N*, except for the negligible renaming of the transition names. Accordingly, the synchronization of the language of the subnets then determines the language of the original net. More precisely, this represents the restriction because, as described above, *L*1*Sy*1∩<sup>2</sup> *L*<sup>2</sup> = *L*1-*L*2. This does not only apply to free Petri nets that have the same final marking as the product of the final marking sets of the subnets. Indeed, for the general case of such a free Petri net that is decomposed, its language can be composed by applying the restriction operator onto the languages of the subnets. Priese and Wimmel show this by transforming the net and its subnets into a normal form that encloses each (sub)net. This normal form transforms all final states of a net into a single final state. That way, it is achieved that the product of the two subnets in normal form (see Definition 3.45) is the final marking of the original net such that the synchronization of the subnets results in the initial net again, i.e., *N* = *N*(*P*1)*sy N*(*P*2). A special case of this restriction is represented by the case in which the languages of two nets *N*<sup>1</sup> and *N*<sup>2</sup> do not have any common letters, such that the synchronization alphabet of the languages of two nets is empty. Because *<sup>L</sup>*1*sy*<sup>∅</sup> *<sup>L</sup>*<sup>2</sup> <sup>=</sup> *<sup>L</sup>*<sup>1</sup> - *L*2, the shuffle can then be used to combine the two languages, such that, for *L*(*N*1) ∩ *L*(*N*2) = ∅, *L*(*N*1)-*<sup>L</sup>*(*N*2) <sup>=</sup> *<sup>L</sup>*(*N*1) -*L*(*N*2)10.

Hence, the restriction operator can be applied if the synchronization alphabet of the languages of the two nets involved in the synchronization represents the intersection of both alphabets, which will be denoted by ∩. That way, the restriction provides an interface that is able to combine the common transitions that occur in the alphabets of both languages. In case there are multiple subnets from a decomposition of a free Petri net, the composition of the languages of two such subnets results in the language of a further subnet. In this case, the languages of the initial net will need to be obtained by a step-by-step composition of the subnet languages. Depending on whether <sup>∩</sup> is empty for all such compositions, the restriction or the shuffle operator needs to be applied. The subsequent definition bases on the presented findings on the synchronization of free (sub)nets and provides a compact notation for the synchronization applied on the languages of a set of subnets.

<sup>10</sup> This synchronization with an empty synchronization alphabet is similar to the binary merge net operator ||, which juxtaposes two marked and labeled Petri nets with disjoint nodes [99].

**Definition 3.46 (Composition of Subnet Languages).** *Given a free Petri net (without isolated transitions) N*(*P*) *with P* = {*p*1,..., *p*|*P*|} *and some positive integer n of disjoint subsets P* ∈ {*P* <sup>1</sup>,..., *P <sup>n</sup>*} *with P* <sup>1</sup> ∪ ... ∪ *P <sup>n</sup>* = *P and P* <sup>1</sup> ∩ ... ∩ *P <sup>n</sup>* = ∅ *for all P* ⊆ *P, the subsequent notation describes the synchronization of the languages of all subnets L*(*N*(*P* )) *to compose the language of the net L*(*N*(*P*))*. Based on the synchronization alphabet* <sup>∩</sup> = *L*<sup>1</sup> ∩ *L*<sup>2</sup> *that represents the intersection of the alphabets of the two languages L*<sup>1</sup> *and L*<sup>2</sup> *involved in the synchronization, two cases may occur:* (1) *For* |∩| > 0 *(in all synchronizations):*

*L*(*N*(*P*)) = *L*(*N*(*P* <sup>1</sup>))*sy*<sup>∩</sup> *L*(*N*(*P* <sup>2</sup>))*sy*<sup>∩</sup> ...*sy*<sup>∩</sup> *L*(*N*(*P <sup>n</sup>*)) = *L*(*N*(*P* 1))-*L*(*N*(*P* 2))- ... -*L*(*N*(*P <sup>n</sup>*)) <sup>=</sup> *<sup>n</sup>* - *i*=1 *L*(*N*(*P i* ))

(2) *For* <sup>∩</sup> = ∅ *(in all synchronizations):*

$$\begin{aligned} L(N(P)) &= \begin{array}{c} L(N(P\_1')) \text{sys}\_{\emptyset} L(N(P\_2')) \text{sys}\_{\emptyset} \dots \text{sys}\_{\emptyset} L(N(P\_n'))\\ &= \begin{array}{c} L(N(P\_1')) \sqcup L(N(P\_2')) \sqcup \dots \sqcup L(N(P\_n')) \end{array} \end{aligned} \\ &= \begin{array}{c} \frac{n}{\sqcup 1} L(N(P\_i')) \end{array} \end{aligned}$$

The synchronization only considers the intersection of the alphabets of the involved languages, which means that, based on the commutativity of the intersection operator, the order of how such a synchronization is applied does not matter in the end. Note that after the restriction has been applied on two languages, e.g. *L*1-*L*2, a restriction with a further language, for example *L*1-*L*2-*L*3, then considers the alphabet of this further language, i.e., *L*<sup>3</sup> , as well as the alphabet of the language resulting from the first restriction, i.e., *L*1-*<sup>L</sup>*<sup>2</sup> (and not only *L*<sup>2</sup> ).

**Composition of the Example SecANet:** Because the subnets resulting from the decomposition of the example SecANet above are free as well, the restriction operator will be used to determine the languages of the compositions of the subnets. More specifically, the language of the DMV example SecANet will be composed step by step in reverse order to the order of the decomposition. Therefore, the languages of the two subnets *NT A* and *NSoD* will be synchronized first. In a further step, the combination of these languages will be synchronized with the initial WF-net *N*. That way, the overall language of the SecANet example will be determined. For the composition of the language of *N*˙ *T A* and *N*˙ *SoD*, the synchronization alphabet is *T A* ∩ *SoD* = {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }. This underlines the fact that the previously indicated special case of the synchronization, namely the restriction, is at hand, such that *L*(*NT A*)*syT A*∩*SoD L*(*NSoD*) = *L*(*NT A*)-*L*(*NSoD*) [167]. Hence, to obtain the language of the two policy-related subnets of the example, the restriction operator for two languages can directly be applied:

*LT A*-*LSoD* <sup>=</sup> ((*LT A* - (*SoD* − *T A*) <sup>∗</sup>) <sup>∩</sup> (*LSoD* - (*T A* − *SoD*) ∗)) <sup>=</sup> ((((*tu*2*t*<sup>1</sup> <sup>∪</sup> *tu*1*t*<sup>1</sup> ) *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> *t*2, *tu*1*t*<sup>1</sup> *t*1) - (*SoD* − *T A*) ∗) <sup>∩</sup> ((*tu*1*t*<sup>1</sup> <sup>∪</sup> *tu*1*t*<sup>2</sup> ) - (*T A* − *SoD*) ∗)) <sup>=</sup> ((((*tu*2*t*<sup>1</sup> <sup>∪</sup> *tu*1*t*<sup>1</sup> ) *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> *t*2, *tu*1*t*<sup>1</sup> *t*1) - (∅) ∗) <sup>∩</sup> ((*tu*1*t*<sup>1</sup> <sup>∪</sup> *tu*1*t*<sup>2</sup> ) - ({*tu*2*t*<sup>1</sup> , *t*1, *t*2}) ∗)) <sup>=</sup> ((({(*tu*2*t*<sup>1</sup> , *tu*1*t*<sup>1</sup> }) *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> *t*2, *tu*1*t*<sup>1</sup> *t*1)) <sup>∩</sup> (({*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }) - ({*tu*2*t*<sup>1</sup> , *t*1, *t*2}) ∗)) <sup>=</sup> ((({*tu*2*t*<sup>1</sup> *<sup>t</sup>*1, *tu*1*t*<sup>1</sup> *<sup>t</sup>*1} *tu*1*t*<sup>2</sup> *t*2, *tu*1*t*<sup>1</sup> *t*1)) <sup>∩</sup> (({*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }) - ({*tu*2*t*<sup>1</sup> , *t*1, *t*2}) ∗)) <sup>=</sup> ((({*tu*2*t*<sup>1</sup> *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> *t*2, *tu*1*t*<sup>1</sup> *t*<sup>1</sup> *tu*1*t*<sup>2</sup> *t*2, *tu*1*t*<sup>1</sup> *t*1})) <sup>∩</sup> (({*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }) - ({*tu*2*t*<sup>1</sup> , *t*1, *t*2}) ∗)) = {*tu*2*t*<sup>1</sup> *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> *t*2, *tu*1*t*<sup>1</sup> *t*1}.

For the composition of the language of this subnet with the language of the WF-net, i.e., *<sup>L</sup> <sup>N</sup>SyN*∩*T A*+*SoD LT A*+*SoD*, the synchronization alphabet is *<sup>N</sup>* <sup>∩</sup>*T A*+*SoD* <sup>=</sup> {*t*1, *t*2}. Hence, the synchronization can be conducted by using the restriction operator again:

$$\begin{aligned} L\_N \widehat{\otimes} L\_{TA+SoD} &= & L(N) \text{syl} \Sigma \cap \Sigma\_{TA+SoD} L(N\_{TA+SoD}) \\ &= & L(N) \text{syl}\_{\{t\_1, t\_2\}} L(\dot{N}\_{TA+SoD}) \\ &= & ((L \sqcup (\Sigma\_{TA+SoD} - \Sigma)^\*) \\ &\qquad \cap (L\_{TA+SoD} \sqcup (\Sigma - \Sigma\_{TA+SoD})^\*)) \\ &= & ((\{t\_1 \, t\_2, t\_1\} \sqcup (\{t\_{u\_1t\_1}, t\_{u\_2t\_1}, t\_{u\_1t\_2}\})^\*) \\ &\qquad \cap (\{t\_{u\_2t\_1}t\_1 \, \sqcup t\_{u\_1t\_2} \, t\_2, t\_{u\_1t\_1} t\_1\} \sqcup (\emptyset)^\*)) \\ &= & ((\{t\_1 \, t\_2, t\_1\} \sqcup (\{t\_{u\_1t\_1}, t\_{u\_2t\_1}, t\_{u\_1t\_2}\})^\*)) \end{aligned}$$

$$\begin{aligned} & \cap \{ t\_{\mathfrak{u}\_2\mathfrak{t}\_1} t\_1 \sqcup \sqcup t\_{\mathfrak{u}\_1\mathfrak{t}\_2} \; t\_2, \; t\_{\mathfrak{u}\_1\mathfrak{t}\_1} t\_1 \} \\ &= & \{ (t\_{\mathfrak{u}\_2\mathfrak{t}\_1} t\_1 \sqcup \sqcup t\_{\mathfrak{u}\_1\mathfrak{t}\_2}) t\_2, \; t\_{\mathfrak{u}\_1\mathfrak{t}\_1} t\_1 \} \end{aligned}$$

Thus, the words that correspond to the set of full firing sequences (or plans) of the example SecANet are given by the set {(*tu*2*t*<sup>1</sup> *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> )*t*2}. The set of obstructed firing sequences (or partial plans) relates to the remaining word that does not contain the end activity *t*2, namely {*tu*1*t*<sup>1</sup> *t*1}.

#### **3.2.4.5 SecANet Language**

In order to determine the SecANet language, the decomposition and the composition of the example SecANet will be generalized. Figure 3.33 depicts the big picture of the SecANet decomposition, in particular the subnets that are to be separated, namely, the WF-net, the user-task subnets and the constraint subnets (i.e., the SoD and BoD subnets). The following considerations will go through this decomposition

**Figure 3.33** SecANet decomposition

step by step in order to determine the essential place subsets in a comprehensive way.

Given a SecANet *NT A*+*C*, its disjoint place subsets *P* and *P*˙ *T A*+*<sup>C</sup>* allow to determine the WF-net *N* and the net modeling the policy *N*˙ *T A*+*C*. The subnet *N*˙ *T A*+*<sup>C</sup>* contains the disjoint place subsets *P*˙ *T A* and *P*˙ *C*, which allow to obtain the subnets *N*˙ *T A* and *N*˙*C*. Based on the disjoint place subsets *P*˙ *CSoD* and *P*˙ *CBoD* , the subnet *N*˙*<sup>C</sup>* can be decomposed into the subnets *N*˙*CSoD* and *N*˙*CBoD* . This results in the four basic disjoint place subsets *P*, *P*˙ *T A*, *P*˙ *CSoD* , and *P*˙ *CBoD* , which will determine the subnets *N*, *N*˙ *T A*, *N*˙*CSoD* , and *N*˙*CBoD* , respectively. The considered place subsets can easily be identified based on the previous SecANet definitions, namely


The policy-related subnets will then be decomposed further into basic subnets that allow to determine their languages straightforwardly. The language of each subnet *N*(*P* ) will be obtained according to the initial marking *m*0,*<sup>P</sup>* and the set of final markings *M <sup>f</sup>* ,*<sup>P</sup>* given by the projection of the initial marking and the terminal markings of the SecANet onto the places *P* of the considered subnet, that is, *m*0,*<sup>P</sup>* = π*<sup>P</sup>* (*m*0) and *M <sup>f</sup>* ,*<sup>P</sup>* = π*<sup>p</sup>* ([*m*0*<sup>T</sup>* ), respectively. The listing below provides an overview of the subnets and languages resulting from the subsequent decomposition and composition.

	- Language of Workflow Subnet *L <sup>N</sup>*
	- User-Task Subnet *Nt*−+
	- Language of the User-Task Subnet *Lt*−+
	- SoD Subnet *N*=
	- BoD Subnet *N*<sup>=</sup>
	- Language of Constraint Subnet *Lc*
	- Language of User-Task Subnets *LT A*

After the languages of the smallest subnets *Nt*−+ and *Nc* are determined, they will be combined with the languages of the other subnets step by step in the course of the composition of languages. Through this step-by-step composition of the languages of all subnets in reverse order to the decomposition, the language of the SecANet will finally be obtained.

To begin with, the workflow subnet can be determined through the places of the initial WF-net. Although structurally, it is equivalent to the initial WF-net, the final markings may differ.

**Definition 3.47 (Workflow Subnet).** *Based on a* SecANet *N*SecANet = -*PT A*+*C*, *TT A*+*C*, *FT A*+*C*, *m*0,[*m*0*<sup>T</sup>* , *TT A*+*C*,*id with mo* ∈ *PT A*+*C, the workflow subnet N* = *N*(*P*) = -*P*, *T* , *F*, *m*0,*P*, *M <sup>f</sup>* ,*P*, *T* , id *is obtained, where P* = {*pi*, *p*1,..., *po*}, *T* = {*t*1, *t*2,..., *t*|*<sup>T</sup>* |}, *F* = {*pi*, *t*1,*t*1, *p*1,...,*t*|*<sup>T</sup>* <sup>|</sup>, *po*}, *m*0,*<sup>P</sup>* = π*P*(*m*0) and *M <sup>f</sup>* ,*<sup>P</sup>* = π*P*([*m*0*<sup>T</sup>* ).

For example, the initial and final markings of the workflow subnet *N* in Figure 3.30a is *m*0,*<sup>P</sup>* = {*pi*} and their set of final markings is *M <sup>f</sup>* ,*<sup>P</sup>* = {{*po*},{*p*2}}.

Since the SecANet formalism is given for arbitrary well-structured free-choice WF-nets, whose comprehensive structure can involve parallelism or exclusive paths, the language of such WF-net can only be defined in general terms. However, the SecANet encoding allows to draw conclusions on the alphabet of the language of the workflow subnet. In fact, the language of the initial WF-net can differ from the language of the WF-net that is decomposed from the SecANet because their final markings may be different. On the one hand, if the workflow is satisfiable, the set of final markings of the workflow subnet still contains {*po*} (as it was the case for the initial WF-net). On the other hand, in case of obstructions, the set of final markings of the workflow subnet may not (only) contain the output place anymore but the markings of the places *p* ∈ *P* that are in the set of obstruction markings *m* ∈ *M*⊗. Hence, since the alphabet of a language consists of all letters that actually occur in at least one word of the language, the actual alphabet of the workflow subnet language determined by the terminal markings of the SecANet can differ from the alphabet of the language of the initial net.

In case of a satisfiable execution, the alphabet of the language of the WF-net contains all workflow tasks. However, in case the workflow is not satisfiable, it does not contain the final marking set {*po*} and therefore not all workflow tasks of the workflow net are reflected in its language *N* . In workflow nets with exclusive branches, it may moreover be possible that only one path is satisfiable, whereas another is not. This would also result in an alphabet *<sup>N</sup>* of the language of the net *N* that would not contain all tasks either.

**Definition 3.48 (Language of the Workflow Subnet).** *Based on the language definition applied on the workflow subnet, the language of a workflow net is L <sup>N</sup>* = *L*(*N*(*P*)) = {w ∈ *T* ∗|∃σ ∈ *T* <sup>∗</sup> ∃*m <sup>f</sup>* ∈ *M <sup>f</sup>* ,*<sup>P</sup>* : *m*0,*P*[σ*m <sup>f</sup>* ∧*h*(σ ) = w}. *The alphabet of L*(*N*(*P*)) *is then:*

$$\begin{split} \Sigma\_{N} = \{ a \in T^{\*} | \begin{aligned} \exists m\_{f} \in M\_{f,P} : m\_{f} = \{ p\_{o} \} \land a \in \{ t | \forall t \in T : m\_{0} | t\_{1} t\_{2} \dots t\_{n} | m\_{f} \} \\ \forall m\_{f} \in \{ P - p\_{o} \} \land a \in \{ t | \forall t \in T : m\_{0} | t\_{1} t\_{2} \dots t\_{t} | m\_{f} \land t\_{t} \notin \uparrow p\_{o} \} \end{aligned} \} \end{split}$$

Hence, in case of an unsatisfiable net (or path), the alphabet of the language of the workflow subnet *<sup>N</sup>* may be a subset of the alphabet defined in the definition of the language-generating workflow subnet. This observation will also be key for the alphabets of the languages for the user-task subnets since, as illustrated in Figure 3.33, a user-task subnet contains the tasks of the workflow subnet as well.

**Definition 3.49 (User-Task Subnets).** *Based on the flattening of user-task authorizations in Definition* 3.30*, the subnet N*˙ *T A* = *N*(*P*˙ *T A*) = -*P*˙ *T A*, *T*˙ *T A*, *F*˙*T A*, *m*0,*P*˙ *T A* , *M <sup>f</sup>* ,*P*˙ *T A* , *T*˙ *T A*, id *is obtained, where P*˙ *T A* = {*pt*1−, *pt*2−,..., *pti*−}∪{*pt*1+, *pt*2+,..., *pti*+}, *T*˙ *T A* = *TT A* = *T* ∪ {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> , *tu*2*t*<sup>1</sup> , *tu*2*t*<sup>2</sup> ,..., *tu <sup>j</sup> ti*}, *F*˙ *T A* = {*pt*1−,*tu*1*<sup>t</sup>* <sup>1</sup> ,*pt*2−,*tu*1*<sup>t</sup>* <sup>2</sup> ,*pt*1−,*tu*2*<sup>t</sup>* <sup>1</sup> ,*pt*2−,*tu*2*<sup>t</sup>* <sup>2</sup> ,...,*pti*−,*tu <sup>j</sup> <sup>t</sup> i* } ∪ {*tu*1*t*<sup>1</sup> , *pt*1+,*tu*1*t*<sup>2</sup> , *pt*2+,*tu*2*t*<sup>1</sup> , *pt*1+,*tu*2*t*<sup>2</sup> , *pt*2+,...,*tu <sup>j</sup> ti*, *pti*+} ∪ {*pt*1+, *t*1,*pt*2+, *t*2,...,*pti*+, *ti*}, *m*0,*P*˙ *T A* = π*P*˙ *T A* (*m*0) and *M <sup>f</sup>* ,*P*˙ *T A* = π*P*˙ *T A* ([*m*0*<sup>T</sup>* ).

For instance, the initial markings and final markings of the user-task subnets *N*˙ *T A* in Figure 3.31a is *m*0,*P*˙ *T A* = {*pt*1−, *pt*2−} and its set of final markings is *M <sup>f</sup>* ,*P*˙ *T A* = {{*pt*2−}, ∅}. The language of each user-task authorization can now be obtained by building the basic subset for each pair of assigned and unassigned places for a single workflow task.

**Definition 3.50 (User-task subnet).** *For each set of pairs Pt*−+ = {*pt*−, *pt*+}*, where t* ∈ *T and Pt*−+ ⊆ *P*˙ *T A, the subnet Nt*−+ = *N*(*Pt*−+) = -*Pt*−+, *TPt*−+ , *FPt*−+ , *m*0,*Pt*−+ , *M <sup>f</sup>* ,*Pt*−+ , *TPt*−+ , id is obtained, where *PPt*−+ = {*pt*−, *pt*+}, *TPt*−+ = {*t*}∪{*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*}, *FPt*−+ = {*pt*−,*tu*1*<sup>t</sup>*,*pt*−,*tu*2*<sup>t</sup>*,...,*pt*−,*tu <sup>j</sup> <sup>t</sup>*}∪{*tu*1*t*, *pt*+,*tu*2*t*, *pt*+,..., *tu <sup>j</sup> <sup>t</sup>*, *pt*+} ∪ {*pt*+, *t*} *m*0,*Pt*−+ = π*Pt*−+ (*m*0) and *M <sup>f</sup>* ,*Pt*−+ = π*Pt*−+ ([*m*0*<sup>T</sup>* ).

Accordingly, Figure 3.34 depicts the user-task subnet *N*(*Pt*2−+) for the task *t*<sup>2</sup> and *Pt*2−+ = {*pt*2−, *pt*2+} of the example SecANet. Its initial marking is *m*0,*Pt* <sup>2</sup>−+ = {*pt*2−} and its set of final markings is *M <sup>f</sup>* ,*Pt* <sup>2</sup>−+ = {{*pt*2−}, ∅}. Hence, in the example of the user-task subnet *N*(*Pt*2−+) resulting from the DMV SecANet, there are actually two final markings, i.e., ∅ relates to the successful execution and {*p*−} corresponds to the obstruction marking. Indeed, there may also be a third final marking {*p*+}, in which only the place indicating assignment is marked (i.e., the state that a user-task transition has been fired) .

**Figure 3.34** User-task subnet for *t*<sup>2</sup>

Whereas for each user-task subnet decomposed from a SecANet, the projection π of the initial marking always results in the initial marking -1, 0 (according to the order {*p*−}, {*p*+}) or {*p*−} in set notation, for the general case, the projection of the terminal marking may result in the maximum number of three final markings, namely -1, 0, -0, 1, and -0, 0, or {*p*−}, {*p*+}, and ∅ respectively. Hence, based on the definition of the L-type language *L*(*N*) = {w ∈ ∗|∃σ ∈ *T* <sup>∗</sup> ∃*m <sup>f</sup>* ∈ *M <sup>f</sup>* : *m*0[σ*m <sup>f</sup>* ∧ *h*(σ ) = w} (with = *T* and *T* = *TPt*−+ ), the initial marking {*p*−} and the three possible final markings (1) {*p*−}, (2) {*p*+}, and (3) ∅, the following three transition firing sequences σ and their corresponding (sets of) words w can be identified.

> For {*p*−}[σ{*p*−}, this results in (1) {*h*(σ )|σ = - } = {w|w = }, {*p*−}[σ{*p*+} yields

(2) {*h*(σ )|σ ∈ {*tut*|*tut* ∈ {*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*}}} = {w|w ∈ {*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*}},

and {*p*−}[σ∅ is reflected in

(3) {*h*(σ )|σ ∈ {*tut*, *t*|*tut* ∈ {*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*}}} = {w|w ∈ {{*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*} · *t*}}}.

(1) and (2) represent the cases in which the workflow task that is associated with the user-task assignment is not executed. Both cases can be caused either by an obstruction or an exclusive path that has not been taken. Here, especially (1) directly indicates an obstruction, in which no transition has been fired at all. However, if the obstruction affects an exclusive path that has not been taken and the workflow is completed (i.e., a marking involving the output place *po* is reached anyway), the obstruction has no effect. However, it could also have been the obstruction itself that lead to the decision to not take the affected path in the first place. In (2), only usertask transitions have been fired. On the one hand, this may encode an assignment of a user to a workflow task in an exclusive path that has not been taken. On the other hand, this may also result from an obstruction beforehand that blocks the execution of further workflow tasks, which users have already been assigned to. In (3), the final marking stands for successful user-task assignments that involve the execution of the workflow task. A firing sequence consists of a user-task transition followed by the transition of the corresponding workflow task.

According to these three cases, the language *L*(*N*(*Pt*−+)) can be denoted for each of the three possible final markings, namely

$$\begin{aligned} L(N(P\_{l-+}), M\_{f, P\_{l-+}} = \{\{p\_{-}\}\}) &= \{\epsilon\}, \\ L(N(P\_{l-+}), M\_{f, P\_{l-+}} = \{\{p\_{+}\}\}) &= \{t\_{u\_{1}l}, t\_{u\_{2}l}, \dots, t\_{u\_{j}l}\}, \\ L(N(P\_{l-+}), M\_{f, P\_{l-+}} = \{\emptyset\}) &= \{\emptyset, \{t\_{u\_{1}l}, t\_{u\_{2}l}, \dots, t\_{u\_{j}l}\} \cdot t\}. \end{aligned}$$

Due to the initial marking provided by the SecANet, the possible permutations of these three final markings are limited. This is because the initial marking directly enables all user-task transitions, such that every user-task subnet is always able to execute each of their user-task transitions (as in case (2)) at least once. A fired user-task transition may, however, only be a prefix of a successful usertask execution (as in case (1)). Hence, the set of final markings of a user-task subnet always contains at least {*pt*<sup>+</sup> } or ∅. Based on this and given some usertask subnet and some possible combinations of the three final markings, the overall language of the user-task subnet can be obtained by the union of the set of words resulting from each marking of the set of final markings. For example, for *M <sup>f</sup>* ,*Pt*−+ = {{*p*−},{*p*+}}, the language *L*(*N*(*Pt*−+)) = { }∪{*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*} is obtained, the set of final markings *M <sup>f</sup>* ,*Pt*−+ = {{*p*−},{*p*+}, ∅} results in the language *L*(*N*(*Pt*−+)) = { }∪{*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*} ∪ {{*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*} · *t*}, and *M <sup>f</sup>* ,*Pt*−+ = {∅} has the language *L*(*N*(*Pt*−+)) = {{*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*} · *t*}. Hence, similarly to the workflow subnet, the alphabet of the language of a user-task subnet may not always involve the workflow tasks, or, more formally:

**Definition 3.51 (Language of the User-Task Subnet).** *Based on the definition of the language applied to the user-task subnet, i.e., L*(*N*) = {w ∈ *T* ∗ *Pt*−+ |∃<sup>σ</sup> <sup>∈</sup> *<sup>T</sup>* <sup>∗</sup> *Pt*−+ <sup>∃</sup>*<sup>m</sup> <sup>f</sup>* <sup>∈</sup> *<sup>M</sup> <sup>f</sup>* ,*Pt*−+ : *<sup>m</sup>*0,*Pt*−+ [σ*<sup>m</sup> <sup>f</sup>* <sup>∧</sup> *<sup>h</sup>*(σ ) <sup>=</sup> <sup>w</sup>}*, the language of a user-task subnet N*(*Pt*−+) *is*

$$L\_{l-+} = L(N(P\_{l-+})) = \{ w \in T\_{P\_{l-+}}^{\*} \mid \qquad \exists m\_{f} \in M\_{f, P\_{l-+}} \; : \; m\_{f} = \{ p\_{-} \} \land \epsilon = w \} $$
 
$$\lor m\_{f} = \{ p\_{+} \} \land w \in \{ t\_{u\_{1}l}, t\_{u\_{2}l}, \dots, t\_{u\_{J}l} \} $$
 
$$\lor m\_{f} = \emptyset \land w \in \{ \{ t\_{u\_{1}l}, t\_{u\_{2}l}, \dots, t\_{u\_{J}l} \} \} \}.$$

*The alphabet of Lt*−+ *is denoted as t*−+ = (*<sup>N</sup>* ∩{*t*})∪{*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*}.

For example, the language of each user-task subnet of the DMV SecANet with its different sets of final markings is *L*(*N*(*Pt*1−+)) = {{*tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> } · *t*1} and *L*(*N*(*Pt*2−+)) = { , *tu*1*t*<sup>2</sup> *t*2}.

Analogously to the decomposition of the user-task subnet *N*˙ *T A*, constraint-related subnets will now be decomposed in order to determine their language. The definitions of SoD- and BoD-related subnets will be explained in order to understand how they can finally be subsumed under the notion of "constraint subnets".

**Definition 3.52 (SoD Subnets)** *Based on the flattening of SoD constraints in Definition* 3.31*, the subnet*

*N*˙*CSoD* = *N*(*P*˙ *CSoD* ) = -*P*˙ *CSoD* , *T*˙ *CSoD* , *F*˙*CSoD* , *m*0,*P*˙ *CSoD* , *M <sup>f</sup>* ,*P*˙ *CSoD* , *T*˙ *CSoD* , id *is obtained, where P*˙ *SoD* = {*SoDu*1*t*1*t*<sup>2</sup> , *SoDu*2*t*1*t*<sup>2</sup> ,..., *SoDu <sup>j</sup> tk tl*}, *T*˙ *SoD* = {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> , *tu*2*t*<sup>1</sup> , *tu*2*t*<sup>2</sup> ,..., *tu <sup>j</sup> tk* , *tu <sup>j</sup> tl*}, *F*˙ *T A*+*SoD* = {-*SoDu*1*t*1*t*<sup>2</sup> , *tu*1*t*<sup>1</sup> ,-*SoDu*1*t*1*t*<sup>2</sup> , *tu*1*t*<sup>2</sup> , -*SoDu*2*t*1*t*<sup>2</sup> , *tu*2*t*<sup>1</sup> ,-*SoDu*2*t*1*t*<sup>2</sup> , *tu*2*t*<sup>2</sup> ,...,-*SoDu <sup>j</sup> tk tl*, *tu <sup>j</sup> tk* ,-*SoDu <sup>j</sup> tk tl*, *tu <sup>j</sup> tl*} *and the markings m*0,*P*˙ *CSoD* = π*P*˙ *CSoD* (*m*0) *and M <sup>f</sup>* ,*P*˙ *CSoD* = π*P*˙ *CSoD* ([*m*0*<sup>T</sup>* )*.*

Similarly to the basic user-task subnets, the basic SoD subnet can be determined:

**Definition 3.53 (SoD Subnet).** *For each SoD place p*= ∈ *P*˙ *SoD, the subnet N*= = *N*(*p*=) = -{*p*=}, *Tp*= , *Fp*= , *m*0,*p*= , *M <sup>f</sup>* ,*p*= , *Tp*= , id *is obtained, where*

$$\begin{array}{l} p\_{\neq} = \{SoD\_{\
u t\_{k}l\_{l}}\}, \\ T\_{p\_{\neq}} = \{t\_{\iota t\_{k}}, t\_{\iota t\_{l}}\}, \\ F\_{p\_{\neq}} = \{\langle SoD\_{\iota t\_{k}l\_{l}}, t\_{\iota t\_{k}}\rangle, \langle SoD\_{\iota t\_{k}l\_{l}}, t\_{\iota t\_{l}}\rangle\}. \end{array}$$

*and the markings m*0,*p*= = π*p*= (*m*0) and *M <sup>f</sup>* ,*p*= = π*p*= ([*m*0*<sup>T</sup>* )*.*

Similarly to SoD subnets, BoD subnets also base on choice-places. However, given a large set of users, they may contain multitudes of outgoing arcs (and transitions).

**Definition 3.54 (BoD Subnets).** *Based on the flattening of BoD constraints in Definition* 3.32*, the subnet N*˙*CBoD* = *N*(*P*˙ *CBoD* ) = -*P*˙ *CBoD* , *T*˙ *CBoD* , *F*˙*CBoD* , *m*0,*P*˙ *CBoD* , *M <sup>f</sup>* ,*P*˙ *CBoD* , *T*˙ *CBoD* , id *is obtained, where P*˙ *T A*+*BoD* = {*BoDu*1*t*1*t*<sup>2</sup> , *BoDu*2*t*1*t*<sup>2</sup> ,..., *BoDu <sup>j</sup> tk tl*}, *T*˙ *BoD* = {*tu*1*t*<sup>1</sup> }∪{*tut*<sup>2</sup> |*tut*<sup>2</sup> ∈ *TT A* − {*tu*1*t*<sup>2</sup> } ∧ *u* ∈ *U* ∧ (*u*, *t*2) ∈ *T A*} ∪ {*tu*2*t*<sup>1</sup> }∪{*tut*<sup>2</sup> |*tut*<sup>2</sup> ∈ *TT A* − {*tu*2*t*<sup>2</sup> } ∧ *u* ∈ *U* ∧ (*u*, *t*2) ∈ *T A*} ∪ ... ∪ {*tu <sup>j</sup> tk* }∪{*tutl* |*tutl* ∈ *TT A* − {*tu <sup>j</sup> tl*} ∧ *u* ∈ *U* ∧ (*u*, *tl*) ∈ *T A*}, *F*˙*BoD* = {-*BoDu*1*t*1*t*<sup>2</sup> , *tu*1*t*<sup>1</sup> }∪{-*BoDu*1*t*1*t*<sup>2</sup> , *tut*<sup>2</sup> |*tut*<sup>2</sup> ∈ *TT A*−{*tu*1*t*<sup>2</sup> }∧*u* ∈ *U*∧(*u*, *t*2) ∈ *T A*} ∪ {-*BoDu*2*t*1*t*<sup>2</sup> , *tu*2*t*<sup>1</sup> }∪{-*BoDu*2*t*1*t*<sup>2</sup> , *tut*<sup>2</sup> |*tut*<sup>2</sup> ∈ *TT A*−{*tu*2*t*<sup>2</sup> }∧*u* ∈ *U*∧(*u*, *t*2) ∈ *T A*} ∪ ... ∪ {-*BoDu <sup>j</sup> tk tl*, *tu <sup>j</sup> tk* }∪{-*BoDu <sup>j</sup> tk tl*, *tutl*|*tutl* ∈ *TT A* −{*tu <sup>j</sup> tl*}∧*u* ∈ *U* ∧(*u*, *tl*) ∈ *T A*} *and the markings m*0,*P*˙ *CBoD* = π*P*˙ *CBoD* (*m*0) and *M <sup>f</sup>* ,*P*˙ *CBoD* = π*P*˙ *CBoD* ([*m*0*<sup>T</sup>* )*.*

Analogously to the SoD subnet, the basic BoD subnet only contains one place.

**Definition 3.55 (BoD Subnet).** *For each BoD place p*<sup>=</sup> ∈ *P*˙ *BoD, the subnet N*<sup>=</sup> = *N*(*p*=) = -{*p*=}, *Tp*<sup>=</sup> , *Fp*<sup>=</sup> , *m*0,*p*<sup>=</sup> , *M <sup>f</sup>* ,*p*<sup>=</sup> , *Tp*= , id *is obtained, where p*<sup>=</sup> = {*BoDu <sup>j</sup> tk tl*}, *Tp*<sup>=</sup> = {*tu <sup>j</sup> tk* , *tutl* |*tutl* ∈ *T*˙ *CBoD* ∧ ∃-*BoDu <sup>j</sup> tk tl*, *tutl* ∈ *F*˙*BoD*}, *Fp*<sup>=</sup> = {-*BoDu <sup>j</sup> tk tl*, *tu <sup>j</sup> tk* } ∪ {-*BoDu <sup>j</sup> tk tl*, *tutl*|*tutl* ∈ *Tp*<sup>=</sup> − {*tu <sup>j</sup> tk* }} *and the markings m*0,*p*<sup>=</sup> = π*p*<sup>=</sup> (*m*0) and *M <sup>f</sup>* ,*p*<sup>=</sup> = π*p*<sup>=</sup> ([*m*0*<sup>T</sup>* )*.*

SoD and BoD subnets both represent elementary nets because they contain only one place. Both have a very similar structure because they only have outgoing transitions. In order to keep the language definition as general and simple as possible, SoD and BoD constraint subnets will be subsumed under "constraint subnets". They allow to encode choice-places with two outgoing user-task transitions affecting the same user (SoD), or one or more outgoing user-task transition(s) affecting different users (BoD).

**Definition 3.56 (Constraint Subnet).** *Let P*˙ *<sup>C</sup>* = {*P*˙ *SoD* ∪ *P*˙ *BoD*} *be the set of places, and T*˙ *<sup>C</sup>* = *T*˙ *SoD* ∪ *T*˙ *BoD be the set of transitions of all constraint subnets. For each constraint place pc* ∈ *P*˙ *C, the subnet Nc* = *N*(*pc*) = -{*pc*}, *Tpc* , *Fpc* , *m*0,*pc* , *M <sup>f</sup>* ,*pc* , *Tp*= , id *is obtained, where*

$$\begin{aligned} T\_{p\_c} &= \{ t\_{\mu t} | \exists \langle p\_c, t\_{\mu t} \rangle \in \dot{F}\_{\mathbb{C}} \land t\_{\mu t} \in \dot{T}\_{\mathbb{C}} \}, \\\\ F\_{p\_c} &= \{ \langle p\_c, t\_{\mu t} \rangle | t\_{\mu t} \in T\_{p\_c} \}, \\\\ m\_{0, p\_c} &= \pi\_{p\_c}(m\_0) \text{ and } M\_{f, p\_c} = \pi\_{p\_c}(\left[ m\_0 \right]\_{\mathcal{T}}). \end{aligned}$$

Accordingly, Figure 3.31b depicts the constraint subnet *N*(*pc*) for the user *u*<sup>1</sup> and *pc* = *pSoDu*1*<sup>t</sup>* 1*t* <sup>2</sup> from the example SecANet. Its initial marking is *m*0,*pc* = {*pSoDu*1*<sup>t</sup>* 1*t* <sup>2</sup> } and its set of final markings is *M <sup>f</sup>* ,*pc* = {∅}.

SoD and BoD constraints that are not in force are reflected in marked constraint places (i.e., the final marking set {*pc*}). A constraint that is applied results in an unmarked constraint place (i.e., the final marking set ∅). Since constraint subnets only consist of one place, the terminal marking of the initial SecANet can result in the maximum number of two possible final marking sets of the constraint subnet. Similarly to the user-task subnet *N*(*Pt*−+), the firing sequences and the corresponding sets of words resulting from these different final markings can be determined according to the definition of the L-Type language *L*(*N*) = {w ∈ ∗|∃σ ∈ *T* <sup>∗</sup> ∃*m <sup>f</sup>* ∈ *M <sup>f</sup>* : *m*0[σ*m <sup>f</sup>* ∧ *h*(σ ) = w} (with = *T* and *T* = *Tpc* .

> For {*pc*}[σ{*pc*}, this results in {*h*(σ )|σ = - } = {w|w = },

#### and {*pc*}[σ∅ determines

{*h*(σ )|σ ∈ {*tut*|∃*pc*, *tut* ∈ *F*˙ *<sup>C</sup>* ∧ *tut* ∈ *T*˙ *<sup>C</sup>*}} = {w|w ∈ {*tut*|∃*pc*, *tut* ∈ *F*˙ *<sup>C</sup>* ∧ *tut* ∈ *T*˙ *C*}}. In contrast to the user-task subnets, constraint subnets do not allow to relate their final markings to successful or obstructed executions. On the one hand, in the example SecANet, the final marking set of the constraint is always ∅, regardless of whether the corresponding firing sequence is satisfiable or obstructed. On the other hand, depending on the number of users that are assigned to tasks affected by a constraint, there may always be constraint places that do take effect and others that do not. In fact, the example "DMV process" rather represents a special case in which the same constraint is applied in every possible firing sequence. The addition of one further user authorized for both tasks would result in terminal markings that would always contain one of the two constraint places. Hence, the set of final markings from all constraint subnets may consist of different combinations of marked constraint places. Analogously to user-task subnets, for each single constraint place and its corresponding subnet, the set of possible markings can be limited as well. In a constraint subnet, the marking ∅ is always part of the set of final markings. This can easily be understood by considering the initial marking of the SecANet encoding again. Here, the initial marking enables all user-task transitions, including those that are affected by all constraint places. Hence, there is at least one firing sequence for each constraint subnet in which each of its outgoing transitions is fireable at least once (i.e., each transition is simply live). Analogously to the determination of the language of a user-task subnet *L*(*N*(*Pt*−+)), and to the observation that there are a maximal number of two different final markings, the language of *L*(*N*(*pc*)) can be determined, namely

$$\begin{aligned} L(N(p\_c)), M\_{f, p\_c} &= \{ (p\_c) \} = \text{(}\n\text{)},\\ L(N(p\_c)), M\_{f, p\_c} &= \{ \emptyset \} ) = \text{(}\n\text{)} \end{aligned} \qquad \begin{aligned} \{\epsilon\}, \\ \{t\_{ut}|\exists \langle p\_c, t\_{ut} \rangle \in \dot{F}\_C \land t\_{ut} \in \dot{T}\_C \}. \end{aligned}$$

If the set of final markings of the constraint subnet contains both possible final markings, the union of these sets of words again constitutes the overall language of the constraint subnet.

**Definition 3.57 (Language of Constraint Subnet).** *Based on the language definition applied to the constraint subnet, i.e., L*(*N*) = {w ∈ *T* <sup>∗</sup> *pc* |∃σ ∈ *T* ∗ *pc* ∃*m <sup>f</sup>* ∈ *M <sup>f</sup>* ,*pc* : *m*0,*pc* [σ*m <sup>f</sup>* ∧ *h*(σ ) = w}*, the language of a user-task subnet N*(*pc*) *is*

$$\begin{aligned} L\_c = L(N(p\_c)) = \{ w \in T\_{p\_c}^\* \mid \qquad \exists m\_f \in M\_{f, p\_c} : m\_f = \{ p\_c \} \land \epsilon = w \} \\ \lor m\_f = \emptyset \land w \in \{ t\_{tt} | \exists (p\_c, t\_{tt}) \in \dot{F}\_C \land t\_{tt} \in \dot{T}\_C \} \end{aligned}$$

*The alphabet of Lc is denoted as <sup>c</sup>* = *Tpc .*

For example, the language of the constraint subnet of the DMV SecANet with the set of final markings {∅} is *L*(*N*(*pc*)) = {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }.

**Composition of Subnet Languages:** The former introduction of the decomposition and the composition of free nets has revealed that the languages of the nets from which the subnets were decomposed can be obtained by using synchronization. In particular, because all SecANet subnets result from the decomposition of free Petri nets, the languages of a net can be composed from the languages of its subnets by applying the restriction (or shuffle) operator onto those subnets. This composition of languages will be conducted in reverse order to the order of how the subnets were decomposed. That way, the languages of subnets are composed step by step until they constitute the language of the initial SecANet, i.e., the languages of the user-task subnets, the constraint nets, their combination and the overall SecANet net will be obtained.

To begin with, after the language of each user-task subnet has been obtained, the languages of all user-task subnets can be composed. As the synchronization alphabet resulting from the intersection of the transitions of each user-task subnet is empty here, as previously observed, a special case of the restriction can be applied, namely the shuffle. Based on Definition 3.46 of the composition of subnet languages, the composition is conducted step by step such that there are intermediate steps in which the resulting languages represent languages of some further subnets of *N*(*P*˙ *T A*). When the language of all user-task pairs have been synchronized, the resulting language is the language of *N*(*P*˙ *T A*). Based on the consideration that at least either {*p*+} or ∅ is a final marking of each user-task subnet, it can be concluded that all user-task transitions are in the alphabet of all user-task subnets, namely *T A*. However, given the case that there is an obstruction that does not allow to execute the workflow task in any firing sequence (i.e. the workflow is not satisfiable), it is possible that not all workflow tasks are in the alphabet of *T A*. This would however also imply that the considered path of the workflow is not satisfiable at all such that affected tasks that are exclusively in the considered path would not be part of the alphabet of the subnet of the workflow itself, namely *N* , either.

**Definition 3.58 (Language of the User-Task Subnets).** *Based on Definition* 3.46*, the composition of the languages of all user-task subnets L*(*N*(*Pt*−+)) *decomposed from N*(*P*˙ *T A*)*, with Pt*−+ ∈ *P*−+ *and P*−+ = {*Pt*−+1,..., *Pt*−+|*P*−+|}*, Pt*−+<sup>1</sup> ∩ ... ∩ *Pt*−+|*P*−+| = ∅*, and Pt*−+<sup>1</sup> ∪ ... ∪ *Pt*−+|*P*−+| = *P*˙ *T A, which results in the language of all user-task subnets L*(*N*(*P*˙ *T A*))*, can be denoted by means of the shuffle operator, namely*

$$\begin{aligned} L\_{TA} = L(N(\dot{P}\_{TA})) &= \begin{array}{c} L(N(P\_{l-+1}))s\chi\_{\emptyset}L(N(P\_{l-+2}))s\chi\_{\emptyset}\dots s\chi\_{\emptyset}L(N(P\_{l-+|P\_{-+}|})) \\ &= \sideset{}{}{}{}{}^{|P\_{l-+|}|}\sideset{}{}{}{}{}\_{L}(N(P\_{l-+i})) \end{array} \end{aligned}$$

*The alphabet of LT A is denoted as T A* = *<sup>N</sup>* ∪ *T*˙ *T A.*

The language of all user-task subnets for the example net is then *L*(*N*(*P*˙ *T A*)) = {{*tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> } · *<sup>t</sup>*1} - { , *tu*1*t*<sup>2</sup> *<sup>t</sup>*2} = {{*tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> } · *<sup>t</sup>*1,{*tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> } · *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> *t*2}.

The language of constraint subnets is composed by applying the restriction operator. Depending on whether the restriction operator acts on two sets of languages that constrain same elements (e.g., the language of the SoD subnets {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> } and {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>3</sup> }), or disjoints sets (e.g., the language of the SoD subnets {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> } and {*tu*2*t*<sup>1</sup> , *tu*2*t*<sup>2</sup> }), it might either restrict the sets of words or only act as a shuffle that allows both sets of words to occur (in case of disjoint sets of transitions), respectively. Because the initial marking allows to fire each user-task transition of a constraint subnet at least once, the alphabet of the resulting language of all constraint subnets encompasses all user-task transitions involved in the constraint subnets.

**Definition 3.59 (Language of Constraint Subnets).** *Based on Definition* 3.46*, the composition of the languages of all constraint subnets L*(*N*(*Pc*)) *decomposed from N*(*P*˙ *<sup>C</sup>*)*, with Pc* ∈ {*Pc*1,..., *Pc*|*P*˙ *C* | }*, Pc*<sup>1</sup> <sup>∩</sup> ... <sup>∩</sup> *Pc*|*P*˙ *<sup>C</sup>* <sup>|</sup> = ∅*, and Pc*1∪...∪ *Pc*|*PC* <sup>|</sup> = *P*˙ *C, which results in the language of all user-task subnets L*(*N*(*P*˙ *<sup>C</sup>*))*, can be denoted by means of the restriction operator, namely* <sup>11</sup>

<sup>11</sup> In contrast to the language of *T A*, constraint subnets may in fact restrict each other because there may be multiple constraints that affect the same user-task transitions.

$$\begin{aligned} L\_{\mathcal{C}} = L(N(\dot{P}\_{\mathcal{C}})) &= \quad L(N(p\_{c1})) \oplus L(N(p\_{c2})) \oplus \dots \oplus L(N(p\_{c|\dot{P}\_{\mathcal{C}}|)})\\ &= \quad \quad \quad \quad \quad \stackrel{|\dot{P}\_{\mathcal{C}}|}{\oplus} L(N(p\_{ci})). \end{aligned}$$

$$\text{The alphabet of } L\_{\mathcal{C}} \text{ is denoted as } \Sigma\_{\mathcal{C}} = \bigcup\_{i=1}^{|\dot{P}\_{\mathcal{C}}|} T\_{p\_{ci}} = \dot{T}\_{\mathcal{C}} \text{ with } \dot{T}\_{\mathcal{C}} \subseteq \dot{T}\_{TA}.$$

For the example SecANet, the language of the single SoD place also represents the language of all constraint subnets because there is only one constraint place, such that *L*(*N*(*P*˙ *<sup>C</sup>*)) = {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }.

To determine the language of all policy-related subnets, the language of the user-task subnets and the language of the constraint subnet can now be composed by means of the restriction operator and can be defined accordingly, namely

$$\begin{split} L\_{TA+C} = L\_{TA} \otimes L\_C &= ((L\_{TA} \sqcup (\Sigma\_C - \Sigma\_{TA})^\*) \cap (L\_C \sqcup (\Sigma\_{TA} - \Sigma\_C)^\*)) \\ &= ((L\_{TA} \sqcup (\emptyset)^\*) \cap (L\_C \sqcup (\Sigma\_{TA} - \Sigma c)^\*)) \\ &= ((L\_{TA} \sqcup \{\epsilon\}) \cap (L\_C \sqcup (\Sigma\_N \cup \{\vec{T}\_{TA} - \vec{T}\_C\})^\*)) \\ &= L\_{TA} \cap (L\_C \sqcup (\Sigma\_N \cup \{\vec{T}\_{TA} - \vec{T}\_C\})^\*)). \end{split}$$

**Definition 3.60 (Language of Policy Subnet).** *The composition of the languages of all policy-related subnets LT A and LC with the synchronization alphabet* = *T A* ∩ *<sup>C</sup>* = *C, which results in the language of all policy subnets L*(*N*(*P*˙ *T A*+*C*))*, can be denoted by means of the restriction operator, namely*

$$L\_{TA+C} = L\_{TA} \circledR L\_C = L\_{TA} \cap (L\_C \sqcup (\Sigma\_N \cup \{\vec{T}\_{TA} - \vec{T}\_C\})^\*))$$

*The alphabet of LT A*+*<sup>C</sup> is denoted as T A*+*<sup>C</sup>* = *T A.*

In the example SecANet, this results in the previously determined language *LT A*-*LSoD* = {*tu*2*t*<sup>1</sup> *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> *t*2, *tu*1*t*<sup>1</sup> *t*1}.

After the policy language is known, the net can finally be synchronized with the workflow subnet. Again, because all synchronizations base on subnets that are decomposed from free Petri nets, the restriction operator is used to determine the SecANet language, namely

$$\begin{aligned} \begin{array}{rcl} L\_{N+TA+C} & & L\_N \oplus L\_{TA+C} \\ & = & ((L\_N \sqcup (\Sigma\_{TA+C} - \Sigma\_N)^\*) \cap (L\_{TA+C} \sqcup (\Sigma\_N - \Sigma\_{TA+C})^\*)) \\ & = & ((L\_N \sqcup (\dot{T}\_{TA})^\*) \cap (L\_{TA+C} \sqcup (\emptyset)^\*)) \\ & = & ((L\_N \sqcup (\dot{T}\_{TA})^\*) \cap (L\_{TA+C} \sqcup (\emptyset)^\*)) \\ & = & ((L\_N \sqcup (\dot{T}\_{TA})^\*) \cap (L\_{TA+C} \sqcup (\epsilon))) \\ & = & ((L\_N \sqcup (\dot{T}\_{TA})^\*) \cap (L\_{TA+C})) \\ & = & (L\_N \sqcup (\dot{T}\_{TA})^\*) \cap L\_{TA} \cap (\Sigma\_N \sqcup (\dot{T}\_{TA} - \dot{T}\_C)^\*)) \end{array} \end{aligned}$$

**Definition 3.61 (SecANet Language).** *The composition of the languages of all workflow and policy-related* SecANet subnets *L <sup>N</sup> and LT A*+*<sup>C</sup> with the synchronization alphabet* = *<sup>N</sup>* ∩ *T A*+*<sup>C</sup>* = *<sup>N</sup> , which results in the language of the* SecANet *L*(*N*(*P*˙ *<sup>N</sup>*+*T A*+*C*)) *or, equivalently, the language of the initial* SecANet *N*SecANet*, i.e., L*(-*PT A*+*C*, *TT A*+*C*, *FT A*+*C*, *m*0,[*m*0*<sup>T</sup>* , *TT A*+*C*,*id*)*, can be denoted by means of the restriction operator, namely*

$$\begin{aligned} L\_{N+TA+C} &= L\_N \circledast L\_{TA+C} \\ &= (L\_N \sqcup (\dot{T}\_{TA})^\*) \cap L\_{TA} \cap (L\_C \sqcup (\Sigma\_N \sqcup (\dot{T}\_{TA} - \dot{T}\_C)^\*)) \end{aligned}$$

The alphabet of *L <sup>N</sup>*+*T A*+*<sup>C</sup>* is denoted as SecANet = *N*+*T A*+*<sup>C</sup>* = *<sup>N</sup>* ∪ *T A*.

For the example SecANet, this definition finally determines the previously identified SecANet language *L <sup>N</sup>*-*LT A*+*SoD* = {(*tu*2*t*<sup>1</sup> *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> )*t*2, *tu*1*t*<sup>1</sup> *t*1}.

#### **3.2.4.6 Language Preservation**

In the course of the flattening (cf. Definitions 3.30, 3.31 and 3.32), the different process aspects have all been integrated into a single representation, the SecANet. The interpretation of how the policy is applied to the process model follows from these definitions and bases on the considerations on fundamental access control modeling concepts, as examined in Chapters 1 and 2. The definitions of the flattening were defined in a way that they encode certain conditions. For example, a user-task transition has to be executed before the corresponding task of the workflow net can be performed, or, based on a constraint, two user-task transitions for different tasks may be in a choice relation with each other. The SecANet definitions then allowed to define satisfiable and obstructed workflows and its related markings and firing sequences (cf. Definitions 3.33 and 3.34). Afterward, based on these definitions, the language of the SecANet was deduced by its decomposition and composition. The impetus for studying Petri net languages was to consider the behavioral integrity of the process aspects at the subnet level and the level of the overall net.

On the one hand, the decomposition of the SecANet revealed the individual languages of the resulting subnets. Here, each subnet language directly relates to the behavior of its initial input. Moreover, the workflow subnet is structurally identical to the initial WF-net. Only the final markings may differ, such that *L <sup>N</sup>* (cf. Definition 3.47) may limit or extend the words of the language of the initial WF-net *L*w*<sup>f</sup>* . This is then also reflected in the possibly different corresponding alphabets *<sup>N</sup>* and w*<sup>f</sup>* . For the user-task authorization and constraint language, their letters and words directly allow retracing their initial inputs. More specifically, the user-task authorization language *LT A* (cf. Definition 3.51 and Definition 3.58) describes only allowed accesses and encodes user-task transition labelings. Each user-task letter *tuti* describes who is assigned to which tasks before the task *ti* is (potentially) executed such that it can easily be retraced to the underlying authorization policy. That way, the modeling of policies provides an expressive language whose words allow to retrace which user has executed which task. Moreover, the constraint language *LC* (cf. Definition 3.57 and Definition 3.59) determines the user-task transitions that are affected by SoD or BoD constraints. Its words encode the different choices provided by applying the constraints onto the given user-task authorization. Since the modeling of constraints introduces only places constraining the user-task transitions, it does not entail any new letters. For example, the language of an SoD subnet consisting of a place *SoDu*1*t*1*t*<sup>2</sup> connected to the corresponding outgoing user-task transitions for which the same user *u*<sup>1</sup> can be assigned to either execute *t*<sup>1</sup> or *t*<sup>2</sup> results in the two words {*tu*1*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }. Each input that is processed into the representation remains unchanged in its behavior on the subnet level. This is also reflected in the alphabets of the two languages *T A* and *<sup>C</sup>* (cf. Definition 3.61 and 3.59). Hence, the previously identified *integrity of inputs* (cf. Section 3.2) can directly be observed from the words of the languages of the subnets as well.

On the other hand, the synchronization allowed to recompose the individual subnet languages, namely, the constraint language, the user-task language, and the language of the workflow subnet. The behavior of the overall process in a PAIS, that is, the SecANet language *L <sup>N</sup>*+*T A*+*<sup>C</sup>* (cf. Definition 3.61), results from their composition. Here, analogously to the language of each subnet, the SecANet language eventually follows from the definitions of the SecANet flattening (cf. Definitions 3.30, 3.31 and 3.32) as well. However, it is still open whether the *integrity of the overall representation* is given (cf. Section 3.2), namely, whether the behavior of the different process aspects is also preserved in the overall SecANet representation. This is supposed to be shown in the following by focusing on each of the different process aspects encoded in the SecANet separately and by relating their initial behavior to their behavior in the refined SecANet model. Because the flattening approach incorporates the policy behavior into the workflow, the foremost question is, to what extent the flattening preserves the language of the initial workflow, as depicted in Figure 3.35. It will moreover be considered whether the behavior of the policy is preserved in the overall net as well. The following section will disambiguate and examine language equivalence and language preservation in the given context.

**Figure 3.35** Language Preservation

While, in general, the question of language equivalence of two nets is not decidable, it is decidable for bounded nets [167].

**Definition 3.62 (Language Equivalence).** *Two Petri nets N*1, *N*2*, where L*(*N*1) = *L*(*N*2)*, are called language equivalent.*

For example, the languages from the initial example DMV workflow net, denoted as *N*w*<sup>f</sup>* , and its SecANet version are *L*w*<sup>f</sup>* = {**t1t2**} with w*<sup>f</sup>* = {*t*1, *t*2} and *L*SecANet = {(*tu*2*t*<sup>1</sup> **t1** *tu*1*t*<sup>2</sup> )**t2**, *tu*1*t*<sup>1</sup> **t1**} with SecANet = {*t*1, *t*2, *u*1*t*2, *u*2*t*1, *u*1*t*2}, respectively (to highlight the difference, *t*<sup>1</sup> and *t*<sup>2</sup> are printed in bold). Although the behavior of the initial inputs can be observed by the letters of the WF-net in the overall SecANet to some extent here, the language *L*SecANet is not equivalent to the language of the initial workflow net *L*w*<sup>f</sup>* , that is, *L*w*<sup>f</sup>* = *L*SecANet. However, besides this strict language equivalence, it can be observed that there are words of the language of the SecANet that contain all letters of the word of the language of the original WF-net in the same order. Such a word whose letters occur in the same order of some word but not necessarily one after another represents a so-called subword (sometimes also called "scattered" subword). Because this points to the intended idea behind the preservation of behavior, subwords and related concepts will now be considered in more detail.

A (scattered) subword *u* of some word v is a word obtained from v by removing any number of letters from arbitrary positions in v. Symmetrically, a superword v is obtained by inserting letters in arbitrary positions of *u*, or, more formally [174]:

**Definition 3.63 (Subword, Superword and Closure).** *Let be some alphabet. A word u* = *a*1*a*<sup>2</sup> ... *am with a*1, *a*2,..., *am* ∈ *is a subword of a word* v ∈ <sup>∗</sup> *if there are words* v0, v1,...,v*<sup>m</sup>* ∈ <sup>∗</sup> *with* v = v0*a*1v1*a*2v<sup>2</sup> ... *am*v*m. This case is denoted as u* v*. If, in addition, u* = v*, it is denoted as u* v *and u is called a proper subword of* v*. The subword relation can also be understood as the embeddability of one word into another, such that, in case that u* v*, it can be said that u embeds in* v*. Moreover,* v *then represents a superword of u as well. The subword property can be used to describe the downward closure of a language L, denoted by L* ↓= {*u* ∈ ∗|∃v ∈ *L* : *u* v}*. It is the set of all subwords, i.e., all words that can be obtained from words in L by deleting letters. On the other hand, the upward closure of L, denoted by L* ↑= {v ∈ ∗|∃*u* ∈ *L* : *u* v}*, is the set of all superwords, i.e., all words that can be obtained from words in L by inserting letters.*

For the word *tu*2*t*<sup>1</sup> *t*1*tu*1*t*<sup>2</sup> *t*<sup>2</sup> of *L*SecANet and the word *t*1*t*<sup>2</sup> of *L*w*<sup>f</sup>* from the example, *t*1*t*<sup>2</sup> *tu*2*t*<sup>1</sup> *t*1*tu*1*t*<sup>2</sup> *t*2. Hence, the behavior of the word *t*1*t*<sup>2</sup> of the initial language is embedded in this word of the language of the SecANet. In this sense, the behavior of the word of the original net is preserved in the refined net. Based on this observation, the question is, whether for all subwords of the SecANet language, i.e., ∀w ∈ {(*tu*2*t*<sup>1</sup> *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> )*t*2, *tu*1*t*<sup>1</sup> *t*1}, the word of the language of the initial WF-net is a subword, that is, *t*1*t*<sup>2</sup> w. If the word of *L*w*<sup>f</sup>* , namely *t*1*t*<sup>2</sup> embeds in all the words in *L*SecANet, it then means that the behavior of the whole SecANet *L*SecANet completely preserves that of *L*w*<sup>f</sup>* . In this case, the initial WF-net language would represent a scattered sublanguage (i.e., a language consisting only of (scattered) subwords) of the SecANet language. The language *L*w*<sup>f</sup>* considered as the "subword language" is only a subset of possible subwords of *L*SecANet. Hence, the aim is not to investigate subword-related properties within one language (e.g., the downward closure) but to compare two languages with regards to the subword property.

This idea of behavioral preservation will be examined more thoroughly by means of the example SecANet and its initial WF-net in the following. Based on the definition of the flattening, it is known that the SecANet introduces new letters. The set of all words of which *t*1*t*<sup>2</sup> is a scattered subword can be overgeneralized as {∗*t*1∗*t*2∗}, with = {*t*1, *t*2, *tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> }. However, in order to obtain the words in *L*w*<sup>f</sup>* (and, thus, to not change the behavior of the initial workflow net), only the letters that do not occur in the original language must be deleted. Hence, in order to only consider the order of letters that are given from the initial WF-net language (i.e., {*t*1*t*2}), all user-task transitions that are not in the initial net are not taken into account, (i.e., the underlined letters {(*tu*2*t*<sup>1</sup> *<sup>t</sup>*<sup>1</sup> *tu*1*t*<sup>2</sup> )*t*2, *tu*1*t*<sup>1</sup> *t*1, *tu*1*t*<sup>2</sup> *t*2}). Therefore, these (underlined) letters are relabeled with silent transitions (which is depicted with black τ -labeled transitions in Figure 3.36). That way, all user-task letters are transformed into the empty word. Such a deletion of only the letters that are not in the words of *L*w*<sup>f</sup>* is supposed to result into proper subwords of the words of *L*SecANet. If the flattening has not changed the behavior of the initial WF-net, these subwords are supposed to be equivalent to all the words of the language of the initial workflow net. Concerning the example, this silencing of all letters that are not in the language of the initial WF-net results in the language {( *t*<sup>1</sup> - )*t*2, *t*1}. Here, only the first created subword ( *t*<sup>1</sup> - )*t*2, which represents a satisfiable execution, is actually the word of the WF-net, i.e., *t*1*t*<sup>2</sup> 12. The other subword {*t*1}, which relates to the obstruction, is not in the WF-net language {*t*1*t*2}. In contrast, this last word represents a subword of the words in the initial WF-net itself. Thus, it must be noted that the SecANet language with terminal markings, which has been considered for the example so far, does not fully preserve the behavior of the WF-net. Although all words in *L*w*<sup>f</sup>* are subwords of words in *L*SecANet, they are not subwords of all the SecANet words, as required initially. More specifically, the resulting subword

<sup>12</sup> Note that not all subwords may embed in the same SecANet words. For example, in workflows with exclusive branching, different subwords embed in different words of the corresponding SecANet.

*t*<sup>1</sup> of *L*SecANet is not a superword of *t*1*t*2, and *t*1*t*<sup>2</sup> is not a subword of the word *t*1. Thus, it is not sufficient to require that all words of *L*w*<sup>f</sup>* are subwords of words of *L*SecANet. In order to achieve a kind of mutual correspondence between the words of the two languages, it must therefore additionally be required that all words in *L*SecANet must be superwords of words from *L*w*<sup>f</sup>* as well.

**Figure 3.36** Flattened net with silent transitions

In summary, in order to have a refined language (i.e., the SecANet language) that truly preserves the behavior of an original language (i.e., the language of the original workflow net), all words in the original language need to be subwords of the refined language, but symmetrically, all words in the refined language are supposed to be superwords of the original language as well. The latter condition then just expresses that the subword property must apply for all words in the SecANet language. It is therefore not a question of language equivalence in the original sense, but a matter as to whether behavior encoded by subwords or superwords finds its respective counterpart in the original (e.g., WF-Net) or refined (SecANet) language respectively. In order to express this more formally, the notion of "complete subword-preservation" will be introduced in the following.

**Definition 3.64 (Complete Subword-Preservation).** *Given two languages L*<sup>1</sup> *and L*<sup>2</sup> *with the same alphabet . If L*<sup>1</sup> *only contains subwords of L*<sup>2</sup> *and L*<sup>2</sup> *only contains superwords of L*1*, L*<sup>1</sup> *completely embeds in L*2*. As the behavior of L*<sup>1</sup> *is then completely embedded in L*2*, it is said that L*<sup>2</sup> *completely preserves the behavior of the words in L*1*. For this case, the subword notation is extended for languages: L*<sup>1</sup> *L*<sup>2</sup> *means all words* w ∈ *L*<sup>1</sup> *are proper subwords of words in* v ∈ *L*<sup>2</sup> *such that* w v*, and all words* v ∈ *L*<sup>2</sup> *are proper superwords of the words* w ∈ *L*<sup>1</sup> *such that* w v*.*

Thus, the behavior of a language *L*<sup>1</sup> is only completely preserved in *L*<sup>2</sup> if the words of *L*<sup>2</sup> do not allow behavior that is not embedable from the words of *L*1. Consequently, *L*<sup>2</sup> represents a subset of the upward closure of *L*<sup>1</sup> ↑ and, *L*<sup>1</sup> is a subset of the downward closure of *L*<sup>2</sup> ↓. For a specific set of deletion letters, typically δ with = *L*<sup>2</sup> − *L*<sup>1</sup> , the two languages are then equivalent. Since the notion of language preservation does not focus on language equivalence but on complete subword-preservation, the envisaged examination on subword-preservation is supposed to carefully consider which SecANet language to take into account. In this regard, in order to investigate the preservation of workflow behavior in the SecANet, the language of the initial workflow net can fully be embedded in the SecANet language only in case of no obstruction. Specifically, this is because the SecANet encoding is not intended to impair satisfiable workflow executions. If there are user-task assignments that do not obstruct the initial workflow, the language of the SecANet in which the corresponding user-task transitions are silenced, is then supposed to be equivalent to the language of the initial workflow net. On the other hand, the SecANet encoding exactly intends to manipulate the behavior of the original WF-net in case of an obstruction. Then, the user-task assignments conflict with the WF-net such that its initial behavior is narrowed down. Therefore, the WFnet behavior can not be preserved in obstruction words of the SecANet. Instead, complete subword-preservation of the workflow language can only be required for satisfiable executions. Hence, in order to exclude obstructions, the set of terminal markings that defines the SecANet language additionally needs to involve *po* (i.e., only satisfiable words are possible).

**Definition 3.65 (Satisfiable SecANet Language).** *The satisfiable* SecANet *language is denoted as L*sat = *L*(-*P*, *T* , *F*, *m*0,[*m*0*<sup>T</sup>* sat, *T* ,*idT* )*, with the set of satisfiable terminal markings*[*m*0*<sup>T</sup>* sat = {*m*|*m* ∈ [*m*0*<sup>T</sup>* ∧*m* ≥ *po*}*.*

That way, the language of the example SecANet can be reduced to only the first set of words, that is, *<sup>L</sup>*sat(SecANet) = {(*tu*2*t*<sup>1</sup> **t1** *tu*1*t*<sup>2</sup> )**t2**} such that only complete executions are considered and obstructions are excluded. Silencing the user-tasktransitions then results in the set of words {( **t1** )**t2**}. Thus, in case of not reaching obstructions, the flattening preserves the behavior of the initial control flow aspect of the example net. Moreover, (SecANet − *<sup>N</sup>* )∗*t*1(SecANet − *<sup>N</sup>* )∗*t*2(SecANet − *N* )∗ can be denoted as the subset of the upward or the downward closure of the SecANet language that illustrates the possibly deleted or filled up words in (SecANet − *<sup>N</sup>* )∗. Interestingly, this can equivalently be expressed by the shuffle operator, namely *t*1*t*2-{SecANet−*<sup>N</sup>* }∗. This again highlights the intended idea of subword-preservation because the shuffle just encodes that the letters of the words involved in the shuffle can appear in any order but letters of the same word, in particular of the original word *t*1*t*2, remain in the same order.

Based on these considerations, the complete subword-preservation is now supposed to be shown for the general SecANet language. Analogously to the deleted letters in the example, the selection of letters to be deleted can be generalized as well. This deletion will subsequently be essential to prove the integrity of the behavior of each process aspect in the overall SecANet. As the focus of this thesis lies on reaching the end of the process, the first step is to prove that the language of the original workflow net is not changed by the SecANet encoding. After that, analogously to the WF-net, it will also be shown that the behavior of the policy is preserved by the SecANet encoding. The subsequent theorem relates the language of the original workflow net to the language of the SecANet, which encodes the policy too.

**Theorem 3.1 (SecANet Workflow Subword-Preservation).** *Let <sup>N</sup> pol* = -*N*w*<sup>f</sup>* , *U*, *T A*,*C be a policy-aware workflow net with the* WF-net *<sup>N</sup>*w*<sup>f</sup>* <sup>=</sup> (*P*w*<sup>f</sup>* , *<sup>T</sup>*w*<sup>f</sup>* , *<sup>F</sup>*w*<sup>f</sup>* , *<sup>m</sup>*0,{*po*}, *<sup>T</sup>*w*<sup>f</sup>* ,*id*)<sup>13</sup> *and N*SecANet = -*PT A*+*C*, *TT A*+*C*, *FT A*+*C*, *mT A*+*C*<sup>0</sup> ,[*mT A*+*C*<sup>0</sup> *<sup>T</sup>* sat, *TT A*+*C*,*id be the corresponding* SecANet. *Then, given that L*sat(*N*SecANet) = ∅*, the* SecANet *completely preserves the behavior of the WF-net L*(*N*w*<sup>f</sup>* )*, such that the words of L*(*N*w*<sup>f</sup>* ) *are*

*subwords that are completely preserved in the words of L*sat(*N*SecANet)*, i.e., L*w*<sup>f</sup> L*satSecANet*.*

Here, the rather elaborate determination of the SecANet language is finally paying off. With its help, the complete subword-preservation can now be proven by simply silencing all transitions that are not in the net under investigation. The deletion homomorphism (cf. Definition 3.37) will be used to assign the empty word to the respective letters, in particular all letters that are not in the WF-net, that is, δSecANet−w*<sup>f</sup>* . Because only the satisfiable SecANet language is regarded, the languages and alphabets of the SecANet subnets are determined by the satisfiable terminal markings as well. For better readability, the subscripted "sat" is here only used for clarification in the beginning. Since, as explained before, the different words can result for obstructed, satisfiable, but also simply exclusive branches, all of the subnet languages defined above (cf. Section 3.2.4.5) basically remain unchanged. The consideration of the satisfiable SecANet language will only make a difference for the language of the workflow subnet and its alphabet. Hence, the investigation of complete workflow subword-preservation can be broken down into the following equation. For this step, all letters in *T A* − w*<sup>f</sup>* are deleted from the SecANet language:

<sup>13</sup> In order to avoid confusion with the workflow subnet *L <sup>N</sup>* , *N*w*<sup>f</sup>* and *L*w*<sup>f</sup>* explicitly describe the initial WF-Net and its corresponding language. *L <sup>N</sup>* relates to the workflow subnet from the SecANet.

*<sup>L</sup>*sat(*N*SecANet) <sup>=</sup> *<sup>L</sup>*sat*N*+*T A*+*<sup>C</sup>* <sup>=</sup> (*<sup>L</sup> <sup>N</sup>* -

 (*T*˙ *T A*) <sup>∗</sup>) <sup>∩</sup> *LT A* <sup>∩</sup> (*LC* - (*<sup>N</sup>* ∪ {*T*˙ *T A* − *T*˙ *<sup>C</sup>*}) ∗), which results in

$$\begin{split} \delta \Sigma\_{TA} - \Sigma\_{wf} (L\_N + TA + \mathcal{C}) & \stackrel{\scriptstyle \bullet}{=} & (\delta \Sigma\_{TA} - \Sigma\_{wf} (L\_N) \sqcup (\epsilon)^{\star}) \\ & \qquad \cap \, \delta \Sigma\_{TA} - \Sigma\_{wf} (L\_{TA}) \cap (\epsilon \sqcup (\Sigma\_N \cup \epsilon)^{\star}) \\ & \stackrel{\scriptstyle \bullet \, \bullet}{=} & L\_N \cap \stackrel{|P\_{-+}|}{\underset{i=1}{\sqcup}} \delta\_{\Sigma\_{TA} - \Sigma\_{wf}} (L\_{t-+}) \cap (\Sigma\_N)^{\star} \\ & \stackrel{\scriptstyle \bullet \, \bullet}{=} & L\_N = L\_{wf} . \end{split}$$

(\*) *LC* = , because deleting the user-task letters from the language of a single constraint subnet

$$L\_c = \{ w \in T\_{p\_c}^\* \mid \begin{aligned} & \quad \exists m\_f \in M\_{f,c} \land \quad \exists m\_f \in M\_{f,c} : m\_f = \{p\_c\} \land \epsilon = w \\ & \quad \lor m\_f = \emptyset \land w \in \{tu\_{\text{if}} \mid \exists (p\_c, t\_{\text{if}}) \in \dot{F}\_C \land t\_{\text{if}} \in \dot{T}\_C\} \end{aligned} \tag{13}$$
 
$$\begin{aligned} & \quad \exists \varepsilon\_{TA} \quad \Sigma\_{wf} \quad (L\_c) = \{w \in T\_{p\_c}^\* \mid \quad \exists m\_f \in M\_{f,c} : m\_f = \{p\_c\} \land \epsilon = w \} \\ & \quad \lor m\_f = \emptyset \land \epsilon = w \} \end{aligned}$$
 
$$\begin{aligned} & \quad \forall m\_f = \emptyset \land \epsilon = w \end{aligned} \qquad \begin{aligned} & \quad \forall m\_f = \emptyset \land \epsilon = w \end{aligned}$$
 
$$\begin{aligned} & \quad \exists \epsilon \right), \quad \begin{aligned} & \quad \not\models\_C \mid \quad \not\models\_C \end{aligned}$$

(\*\*) Because *LT A* <sup>=</sup> <sup>|</sup>*P*−+| - *i*=1 *<sup>L</sup>*(*N*(*Pt*−+*i*)) then δ*T A*−w*<sup>f</sup>* (*LT A*) <sup>=</sup> <sup>|</sup>*P*−+| - *i*=1 δ*T A*−w*<sup>f</sup>* (*Lt*−+). Deleting the user-task assignment transitions from the language of a single user-task subnet

$$\begin{aligned} L\_{t \to +} &= \{w \in T\_{P\_{l \to +}}^{\*} \mid \qquad \exists m\_{f} \in M\_{f, P\_{l \to +}} : m\_{f} = \{p\_{-}\} \wedge \epsilon = w\} \\ &\quad \lor m\_{f} = \{p\_{+}\} \wedge w \in \{t\_{u1}, t\_{u2}, \dots, t\_{u\_{f}l}\} \\ &\quad \lor m\_{f} = \emptyset \land w \in \{\{t\_{u1}, t\_{u2}}, \dots, t\_{u\_{f}l} \in \{\}\} \\ \delta\_{\Sigma\_{I\to} - \Sigma\_{wf}}(L\_{t \to +}) &\quad \quad \exists m\_{f} \in M\_{f, P\_{l \to +}} : m\_{f} = \{p\_{-}\} \wedge \epsilon = w \\ &\quad \quad \lor m\_{f} = \{p\_{+}\} \wedge \epsilon = w \\ &\quad \lor m\_{f} = \{p\_{+}\} \wedge \epsilon = w \} \\ &\quad \text{such that, for a task } t \text{ that occurs in all executions,} \\ \delta\_{\Sigma\_{I\to} - \Sigma\_{wf}}(L\_{t \to +}) &\quad \vdash \end{aligned}$$

and, for a task t that does not occur in all executions,

$$
\delta\_{\Sigma\_{TA} - \Sigma\_{wf}}(L\_{t-+}) = \{\epsilon, t\}.
$$

(\*\*\*) Depending on whether the workflow net contains exclusive branches or not, two cases can be distinguished: (1) In sequential workflows, all tasks need to be executed to complete the workflow, such that *L*w*<sup>f</sup>* = {*t*<sup>1</sup> ... *t*|*T*w*<sup>f</sup>* |}, that means, the execution order of each task involved in the workflow is unconstrained. Hence, for a corresponding *LT A*, deleting the user-task letters results in the set of words *LT A* = {*t*<sup>1</sup> - ... *t*|*T*w*<sup>f</sup>* |} (based on Definition 3.30, it directly follows that the number of place pairs |*P*−+| results from the number of tasks |*T*w*<sup>f</sup>* |). In parallel workflows, all tasks occur as well. However, concurrent tasks may occur in different orders, such that *LT A* would involve all the task as well, namely *LT A* = {*t*<sup>1</sup> - ... *t*|*T*w*<sup>f</sup>* |}. Hence, given that every task may only occur once, *t*<sup>1</sup> - ... *t*|*<sup>T</sup>* <sup>|</sup> is the least restrictive order in which the tasks of the workflow may occur because all tasks are shuffled arbitrarily. Consequently, it can directly be observed that *LT A* contains all the words of *L*w*<sup>f</sup>* as well, wherefore the intersection of *L*w*<sup>f</sup>* with *LT A* is just *L*w*<sup>f</sup>* itself. (2) In workflows that additionally involve exclusive branches, a workflow can be completed even though not all of its tasks are involved. For example, a workflow of three tasks may have the language *L*w*<sup>f</sup>* = {*t*1*t*2*t*3, *t*1*t*3} (i.e., *t*<sup>2</sup> may be executed or not). With regards to the subsequent language of *LT A*, this can be subsumed as *L*w*<sup>f</sup>* = {*t*<sup>1</sup> · { , *t*2} · *t*3} and would then also be reflected in the corresponding *LT A* = {*t*<sup>1</sup> - { , *<sup>t</sup>*2} *t*3}. In other words, if is additionally given for a task *t*, it corresponds to the possibility given by the workflow to leave out this task (or letter). When it comes to tasks in exclusive branches, the languages of the corresponding user-task subnets *Lt*−+ is {*t*, } (i.e., the branch in which the task *t* occurs is chosen or not). In a rather theoretic workflow in which all tasks are in mutually exclusive branches this would then result in *LT A* = {{ , *<sup>t</sup>*1} - ... - { , *t*|*T*w*<sup>f</sup>* |}}. Similarly to (1), for workflows that involve exclusive branches, it can directly be observed that *LT A* contains all the words of *L*w*<sup>f</sup>* as well because all task that may (or may not) occur can be arbitrarily shuffled. *LT A* then contains all possible combinations of occurrence and non occurrence of the tasks given by the initial workflow. For example, the fictive workflow would involve all words from to *t*<sup>1</sup> - ... *t*|*T*w*<sup>f</sup>* <sup>|</sup>. Thus, the intersection of *L*w*<sup>f</sup>* with *LT A* is just *L*w*<sup>f</sup>* itself again. Hence, for both cases (1) and (2), because *LT A* does not correspond to the workflow structure encoded in *L <sup>N</sup>* but provides all possible combination of (optional or exclusive) tasks, it represents a less restrictive language than *L*w*<sup>f</sup>* . Moreover, because only satisfiable executions are considered, namely all possible terminal firing sequences of the initial workflow, the language of the workflow subnet and its alphabet are identical to the language and alphabet of the initial workflow, such that *L <sup>N</sup>* = *L*w*<sup>f</sup>* and *<sup>N</sup>* = w*<sup>f</sup>* . Thus, the words of *L*w*<sup>f</sup>* completely embed in the words of *L*satSecANet, such that *L*w*<sup>f</sup>* is a scattered sublanguage of the *L*satSecANet and *L*w*<sup>f</sup> L*satSecANet. Hence, concerning satisfiable executions, the behavior of the original workflow net is completely preserved in the behavior of the SecANet.

In order to investigate whether the policy behavior is preserved in the SecANet, now, the workflow related transitions will now be removed instead. As the focus does not lie on the original WF-net here, it is sufficient to delete only those workflow tasks that actually occur in the language of the net, such that the deletion homomorphism is δ*<sup>N</sup>* . Whereas the policy behavior has been flattened into the initial workflow net, there are no initial policy nets into which the WF-net is incorporated. The integrity of the policy behavior can thus not be examined directly because there is no initial net model of the policy and no initial language of a policy-net, in particular, of an authorization or a constraint net comparable to the initial WF-net. Therefore, this behavioral preservation can be shown to a limited extent only. It will only be examined whether the languages of the subnets, which, as previously determined, fully represent their inputs, are retained in the overall SecANet language if the workflow tasks are neglected. Because satisfiability corresponds to the complete execution of the initial workflow, considering only policy parts that lead to satisfiable executions would limit policy behavior here. Therefore, all possible terminal SecANet executions need to be regarded. That way, the policy behavior is still fully reflected, notwithstanding the consequences for the workflow, namely its satisfiability or obstructability. This is supposed to show that at least the languages of the subnets that encode the policy are fully preserved in the language of the SecANet.

**Theorem 3.2 (SecANet Policy Subword-Preservation).** *Let N pol* <sup>=</sup> -*N*, *U*, *T A*,*C be a policy-aware workflow net with the WF-net N* = (*P*, *T* , *F*, *m*0,{*po*}, *T* ,*id*)*, the set of users U, the user-task authorization T A* ⊆ *U* × *T and the set of constraints C and let N*SecANet = -*PT A*+*C*, *TT A*+*C*, *FT A*+*C*, *mT A*+*C*<sup>0</sup> ,[*mT A*+*C*<sup>0</sup> *<sup>T</sup>* , *TT A*+*C*,*id be the corresponding* SecANet. *Then, the* SecANet *completely preserves the behavior of the policy, such that it completely embeds the policy-related words of the languages LT A* and *LC, which encode the user-task authorization T A and the constraints C, i.e.,* δ*<sup>N</sup>* (*LT A*) *L*SecANet and δ*<sup>N</sup>* (*LT A*)(*LC*) *L*SecANet.

The deletion of the WF-task letters in *<sup>N</sup>* from the SecANet language

$$L\_{N+TA+C} = (L\_N \sqcup (\dot{T}\_{TA})^\*) \cap L\_{TA} \cap (\delta\_{\Sigma\_N}(L\_C) \sqcup (\Sigma\_N \cup (\dot{T}\_{TA} - \dot{T}\_C))^\*),$$
 
$$\text{results in}$$
 
$$\begin{split} \delta\_{\Sigma\_N}(L\_{N+TA+C}) &= (\epsilon \sqcup (\dot{T}\_{TA})^\*) \cap \delta\_{\Sigma\_N}(L\_{TA}) \cap (\delta\_{\Sigma\_N}(L\_C) \sqcup (\epsilon \sqcup \dot{T}\_{TA} - \dot{T}\_C))^\*) \\ &= (\dot{T}\_{TA})^\* \cap \delta\_{\Sigma\_N}(L\_{TA}) \cap (\delta\_{\Sigma\_N}(L\_C) \sqcup (\dot{T}\_{TA} - \dot{T}\_C))^\* \\ &= \delta\_{\Sigma\_N}(L\_{TA}) \cap (L\_C \sqcup (\dot{T}\_{TA} - \dot{T}\_C))^\* \\ &\overset{\ast}{=} \overset{|P\_{\to}|}{|i|} \delta\_{\Sigma\_N}(L\_{I-+}) \cap L\_C \sqcup (\dot{T}\_{TA} - \dot{T}\_C))^\* \end{split}$$

∗∗

$$\equiv \qquad \qquad \qquad \delta\_{\Sigma\_N}(L\_{TA})\_j$$

 *LT A* without the workflow transitions

$$
\cap (L\_{\mathcal{C}} \sqcup \dotsb \sqcup \underbrace{\{\dot{T}\_{TA} - \dot{T}\_{\mathcal{C}}\} \urcorner}\_{},
$$

Kleene closure of user-task transitions not involved in any constraint

(\*) *LC* is not affected by the deletion because it does not contain any workflow task letter and, thus, remains unchanged. The language that encodes user-task assignments

$$\begin{aligned} L\_{l-+} &= \{ w \in T\_{P\_{l-+}}^{\*} \mid & \exists m\_{f} \in M\_{f, P\_{l-+}} : m\_{f} = \{ p\_{-} \} \wedge \epsilon = w \\ & \lor m\_{f} = \{ p\_{+} \} \wedge w \in \{ t\_{u\_{l}l}, t\_{u\_{2}l}, \dots, t\_{u\_{f}l} \} \\ & \lor m\_{f} = \emptyset \land w \in \{ \{ t\_{u\_{l}l}, t\_{u\_{2}l}, \dots, t\_{u\_{l}l} \} \cdot t \} \} \text{ results in} \\ \delta\_{\Sigma\_{N}}(L\_{l-+}) &= \{ w \in T\_{P\_{l-+}}^{\*} \mid & \exists m\_{f} \in M\_{f, P\_{l-+}} : m\_{f} = \{ p\_{-} \} \wedge \epsilon = w \\ & \lor m\_{f} = \{ p\_{+} \} \wedge w \in \{ t\_{u\_{l}l}, t\_{u\_{2}l}, \dots, t\_{u\_{l}l} \} \\ & \lor m\_{f} = \emptyset \land w \in \{ \{ t\_{u\_{l}l}, t\_{u\_{2}l}, \dots, t\_{u\_{l}l} \} \} \}. \end{aligned}$$

such that, when its comes to user-task transitions that always occur, δ*<sup>N</sup>* (*Lt*−+) = {*tu*1*t*,..., *tu <sup>j</sup> <sup>t</sup>*}, and δ*<sup>N</sup>* (*Lt*−+) = { ,{*tu*1*t*, *tu*2*t*,..., *tu <sup>j</sup> <sup>t</sup>*}} concerning user-task transitions that are in exclusive relation with user-task transitions for other tasks (due to some constraints). Hence, the behavior of the authorization is still encoded in the name of the transition directly resulting from the construction rule (cf. Definition 3.30), and all these transitions together still constitute the complete picture of the initial authorization policy. The constraints operating on it are still encoded directly in the respective constraint places and the associated outgoing transitions.

.

Thus, the words in *LT A* still allow drawing direct conclusions on the underlying initial authorization policy. As explained before, with regard to *LC*, this is only possible if there are user-task authorizations for which the existing constraints can actually be applied as well.

(\*\*) It can directly be observed that the policy-related behavior encoded in *LT A* and *LC* is not changed if only the policy-related user-task transitions of the SecANet language are regarded. The composition of both languages δ*<sup>T</sup>* (*LT A*) and *LC* that results in the overall policy-behavior is realized by the Kleene closure of the user-task transitions not involved in any constraints. If the transitions of the constraints exactly correspond to the transitions in the language of the user-task assignments, it is empty and results in . With the help of the shuffle operator, the Kleene closure provides the missing links such that the constraint language and user-task language can be intersected. In particular, based on *LC*, words can be built that are also in *LT A*, whereby the intersection operator limits these words to exactly those words which also occur in *LT A*. That way, the language that encodes the policy combines the user-task language and the constraint language and fully embeds in the SecANet language, such that its behavior is completely preserved as well, i.e., δ*<sup>N</sup>* (*LT A*) *L*SecANet and δ*<sup>N</sup>* (*LT A*)(*LC*) *L*SecANet.

In conclusion, it has been shown that the behavior of all process aspects is embedded in the overall SecANet, which means that the integrity of the overall representation is preserved. In this regard, the words encoding workflow or policy behavior represent a subset of the downward closure of the SecANet language. In turn, the SecANet language represents a subset of the upward closure of the words encoding the initial inputs. Just as, in general, the upward closure offers an overapproximation of system behavior [137], the SecANet behavior can be seen as an over-approximation of the behavior of the initial inputs. The results of this languagerelated examination can directly be used to interpret the words of different language types. For example, in terms of a terminal language, one can immediately conclude from the SecANet property of complete subword-preservation that words that can be embedded from the language of the initial WF-net are satisfiable words. In the opposite case, if there are SecANet words that are not superwords of words from the language of the initial workflow net, they do not encode complete process executions and, thus, represent obstructions.

#### **3.2.5 Cyclic Behavior and Policy Re-Enactment**

The SecANet encoding presented so far is designed in such a way that each user can be assigned only once and each task can be executed only once. The tokens that enable user-task assignments can be consumed but not produced, hence the overall number of tokens at the end of execution is smaller than the number of tokens in the initial marking. If a workflow execution were to enter a loop in an as-yet-acyclic encoding of a SecANet, the net constructs encoding the policy would lack the tokens to continue to provide its desired functionality. Thus for a comprehensive workflow structure with cyclic behavior, how can the encoding remain functional if its tasks are supposed to be executed multiple times?

First of all, simply restoring the initial tokens would fall short, since there would be a danger of manipulating the original encoding and behavior of a SecANet. This can be illustrated for the places of constraints as well as the places of user-task subnets. It can be observed that constraint places always become empty in the course of a user-task assignment, that is, a firing of a user-task transition. Thus the number of empty constraint places always corresponds to the number of executed user-task assignments to which these constraints apply. Even if all tasks of a workflow were affected by constraints and all tasks were executed, the number of constraint places containing no tokens could not exceed the number of tasks. Hence in cases where the number of constraint places is greater than the number of tasks for which the constraint places were encoded, there are always some marked constraint places left after the tasks are executed. In user-task subnets, there may be cases in which a task is not finally assigned at all, although the user-task assignment has already been executed (cf. Section 3.2.4.5). Therefore, there may be leftover tokens in places of user-task constructs as well. Hence for all places of the policy subnets, it must always be assumed that there are leftover tokens when entering a loop before the initial marking is created again. To restore the initial marking, moreover, one could consider bounding the capacity of the initially marked places to 1, and in that way ensure safeness. However, although this would reduce the possible combinations of places containing leftover tokens (because the initially marked places could be neglected), it would cause other problems. Up to now, the SecANet encoding allows each place to contain an unlimited number of tokens. Such a Petri net is referred to as an infinite-capacity net. A finite-capacity Petri net, in contrast, is one in which there is a maximum number of tokens defined for each place. For such Petri nets, there is an additional firing rule which says that after firing a transition the numbers of tokens in its output places must not exceed their maximum capacities. Since the firing rule then needs to consider the outgoing places, this would change the desired condition-event principle. A condition that is fulfilled would not imply enabledness, which would confuse the interpretation of the behavior of a SecANet.Moreover, such an additional firing rule represents an extension that is comparable, for instance, to the introduction of further tokens in colored Petri nets (which also implies further firing rules or arc weights). Hence to keep the intuitive understanding of the SecANet model and sustain the possibility of applying rather efficient techniques to it, additional firing rules are avoided, as elaborated earlier. Moreover, each pure finite-capacity net can be transformed into an infinite-capacity net [155]. As depicted in Section 3.2.3.1, the user-task construct represents an example of such a transformation. Therefore, a slightly higher modeling complexity is preferred in order to keep the Petri nets as simple as possible and yet preserve the established properties.

Thus all possible token distributions in the parts of the policy subnets that are affected by a loop have to be considered before the initial markings can be restored. For this, the concept of "policy re-enactment" will subsequently be presented. Such a measure aims to restore the initial functionality of the (affected part of the) policy, that is, to "re-enact" it. To ensure this, all leftover tokens in policy places are supposed to be consumed before the initially marked policy places are marked again. Although this encoding will be more complex than the encoding for acyclic nets, it will preserve the concept of an encoding described in the acyclic case. Thus in order not to compromise the established SecANet properties, the re-enactment constructs must be constructed of safe, plain, and pure infinite-capacity P/T net parts as well. In this process, the idea is to ensure only the desired functionality but not to interfere with the behavior of the SecANet. The focus will thus not be on the looping behavior, the transitions, or the language of the loops, but instead on how the initial marking for the policy parts affected by a loop can be obtained again, hence the possible states (or token distributions) will be crucial. Accordingly, the re-enactment constructions are designed in such a way that they eventually act only for routing purposes, so that all transitions involved in the re-enactment constructions could actually be silenced and yet cyclic SecANet behavior would still be supported.

To some extent, the basic idea of the net constructions discussed below can be compared to so-called "start, run, clear" Petri net constructions. They control the execution of a Petri net and can be used to obtain the previously mentioned normal forms, for example always with the same initial and end markings [167]. The objective of the re-enactment constructions will not be an entire net, but only the parts of the subnets that involve user-task authorizations and constraints. As such, it will focus only on the potential end markings and initial markings in the specific context of the SecANet encoding. (A "run" place controlling each transition of the entire execution is not necessary, and in fact would represent an undesired self-loop.) In all of this, it is key to recall that the process models considered for this approach are well-structured and have clean constructions that avoid "short circuits" between loops. In this regard, as explained earlier, single-entry and singleexit points are assumed for the loops in a net [110] (cf. Section 3.1.2.4 on blockstructured models). Because of the many existing techniques, approaches, and tools for identifying cycles in Petri nets, the question here is not how to identify cycles, but rather which parts of the policy should be reset—and in which way—if a cycle is entered.

In what follows, first the general idea of re-enactment, and how such a "reenactment block" can be nested will be presented. Then this idea will be generalized and formalized in the course of the "flattening of policy re-enactment" into a SecANet. Since the previous modeling steps of a SecANet already encode certain information, the modeling of re-enactment for constraints and authorizations focuses on the SecANet, and not on the policy states in the original policy-aware WF-net. This allows for building on the knowledge already encoded in the acyclic modeling.

#### **3.2.5.1 Points and Scopes of Policy Re-Enactment**

From a control-flow perspective, cycles or loops are self-explanatory. In contrast to acyclic workflow structures, cyclic workflows typically contain workflow tasks that lie on cyclic paths and can therefore occur multiple times. From an organizational point of view, however, this raises the question of what effects cycles in the control flow can have on policy aspects and vice versa. Here, the current policy encoding in a SecANet would allow execution of each task only once, so that it would block tasks that are to be executed again. Therefore, a cyclic path demands that the parts of the policy involved in it be re-enacted in such a way that users can eventually be assigned again after a cycle is entered. For this, the concept of "re-enactment points" will be introduced. This supports "forgetting" previous user assignments and re-assigning users to tasks that lie in the scope of a cyclic path for a specific policy part.

**Figure 3.37** DMV with loop and re-enactment point - *R*{*t*1,*t*2}

A "re-enactment point" is considered as an event in the workflow execution that triggers the re-enactment of the policy for a specific scope of tasks. It allows fine-grained modeling and control of the position in the workflow at which the re-enactment is triggered. Figure 3.37 proposes the notation of such an event in the context of a BPMN notation of the DMV process. Thus a re-enactment could even be triggered for acyclic nets in order to force policy enactment to forget user-task assignment decisions that had already been made, for example on certain exclusive paths. In this regard, the proposed policy re-enactment can be related to the notion of "release points" [24], which intends to erase the execution history for certain constraints as well. Release points are defined directly within the SoD or BoD constraints. Re-enactment points, in contrast, focus on the tasks affected by the policy and are not part of the constraint definition. This allows them to easily be considered for the authorization policy as well. Just as with a release point, a re-enactment point explicitly defines its scope, while a loop only implicitly defines the scope to which it applies. Hence for cyclic behavior a re-enactment point can be used to explicitly state the loop-entry point for the entire block of tasks involved in the loop. Indeed, it is assumed that re-enactment points are explicitly stated and defined in the course of the model and policy design, because there are many approaches that can be used to identify the entry and exit point of a loop, or the looping block. These approaches address the identification of (the smallest) cycles, cyclicity, and repetitiveness in Petri nets or WF nets—for example, with the help of the reachability graph, the so-called T-invariant, or more sophisticated techniques [22, 74, 75, 155]. Since the boundedness of a net is decisive in the identification of cycles, for unbounded nets becomes more complex. For free-choice nets, in contrast, cycles can be identified efficiently. Based on the results of the identification of cycles, the re-enactment points involving the scopes of workflow tasks covered by each cycle could then be added right after the entry point of the cycle. Thus re-enactment points provide different possibilities for steering and control of the execution of a security-aware workflow. On the one hand, a re-enactment point could be used to explicitly trigger

**Figure 3.38** DMV Petri net with loop and re-enactment transition - *t* {*t*1,*t*2}

a policy re-enactment for the scope of a cycle when its loop entry point is passed. On the other hand, a conscious omission of a re-enactment point after loop entry could be used to force taking a path that executes tasks that have not yet been assigned.

Thus re-enactment points are characterized by their position and the scope they define, which determines the tasks that are to be re-enacted. Here, to preserve the basic functionality of a SecANet, it is assumed that the definitions of the reenactment points are reasonable. For example, if a re-enactment point is entered after loop entry, it should cover all tasks involved in the loop in order to prevent manipulation of workflow behavior. Since the actual position of such a point in the workflow structure has an impact on the execution [39], the position of the reenactment point is assumed to be reasonable. For example, if a loop is entered, the corresponding re-enactment point is supposed to occur right after loop entry. If a re-enactment point is intended to release a certain scope of tasks, it needs to be triggered right before that scope. Otherwise, re-enactment points at arbitrary positions may negatively impede the behavior of the SecANet, since they quickly become confusing and may cause unintended dependencies between the positions of the re-enactment points and the workflow execution. Thus to ensure a clear structure and preserve the encoding, a re-enactment point for acyclic SecANet (parts) may occur only right before or right after the scope to which it applies.

**Re-Enactment Transitions:** Analogously to the general concept of a "reenactment point" in a process, "re-enactment transitions" for Petri nets are introduced. The workflow net in Figure 3.38 depicts the WF-net of the BPMN example in Figure 3.37. It contains the re-enactment transition - *t* {*t*1,*t*2}, which defines the re-enactment point and the scope of tasks that are to be re-enacted. In general, - *t S* denotes a transition that triggers re-enactment of a given scope of tasks *S* ⊆ *T* .

**Definition 3.66 (Re-Enactment Transitions and Scopes).** *Given a* SecANet *N, let* - *t <sup>S</sup> be a transition that represents a re-enactment point, and let S* ⊆ *T be the corresponding scope that defines a set of tasks for which the policy is supposed to be re-enacted. Then the set of all re-enactment transitions in a WF-net is denoted by* - *T <sup>S</sup> . The non-empty set of all scopes S of all transitions triggering re-enactment is denoted by a family of sets, S*- *<sup>T</sup>* = {*S*1,..., *<sup>S</sup>*|*S*|}*.*

For example, given the three different scopes *S*<sup>1</sup> = {*t*1, *t*2}, *S*<sup>2</sup> = {*t*3, *t*4}, and *<sup>S</sup>*<sup>3</sup> = {*t*1, *<sup>t</sup>*2, *<sup>t</sup>*3, *<sup>t</sup>*4, *<sup>t</sup>*5}, the three re-enactment tasks can be denoted by - *<sup>t</sup> <sup>S</sup>*<sup>1</sup> , - *<sup>t</sup> <sup>S</sup>*<sup>2</sup> , and - *<sup>t</sup> <sup>S</sup>*<sup>3</sup> (equivalently, as - *t* {*t*1,*t*2}, - *<sup>t</sup>* {*t*3,*t*4}, and - *t* {*t*1,*t*2,*t*3,*t*4,*t*5}), hence *S*- *<sup>T</sup>* = {{*t*1, *t*2},{*t*3, *t*4},{*t*1, *t*2, *t*3, *t*4, *t*5}}.

**Cancellation and Enactment:** Based on such a re-enactment transition, an example of a Petri net construction for two tasks *ti* and *tj* , similar to the example DMV SecANet, is used to sketch the idea of how the policy for a certain scope can be re-enacted. As soon as re-enactment is triggered, tokens are supposed to be consumed and produced in such a way that the initial state of the considered policy encoding is restored. The bright upper part in Figure 3.39 shows the idea of how the re-enactment is implemented. First, an "enter re-enactment" transition produces a token in the "cancellation control" place. In order to avoid self-loops, the cancellation transitions are connected to a further place whose outgoing transition also produces a token in "cancellation control." It is assumed that there is no obstruction, since that would block the execution of the tasks and no loop could be carried out. Therefore, both user-task assignments are considered to be executed, hence in this example there are no leftover tokens in the places of the user-task encodings. Thus the cancellation needs to consider only the SoD-related encoding here. For every SoD place, a transition that can consume leftover tokens is added (cf. the "cancel" transitions). After all leftover tokens in the regarded places are erased, the "enact" transition can be fired to put one token back into the initially marked SoD and user-task assignment places. To ensure that this "enactment" can be performed only when all corresponding SoD places are empty and to avoid having two tokens in an SoD place, their capacity needs to be explicitly bounded by 1. Based on the previously introduced "complementary-place transformation" [155], complementary places can be used to achieve this. They are labeled with the place they are complementing, followed by "\_c1c" (capacity-1 complement). Moreover, arcs are added to the transitions which are connected to the regarded places. Here, the sum of tokens for each pair that consists of an SoD place and its place-complement is always equal to the capacity (which is 1 in this case) before and after executing the regarded transitions. While the purpose of Figure 3.39 is to explain the basic idea of re-enactment, the idea of cancellation and enactment will be formalized in a more fine-grained way. For example, the fulfillment of the condition that all leftover tokens are erased before the "enact" transition can produce tokens in the initially marked places will be partitioned into multiple steps. This higher modularity will allow the cancellation and enactment to be controlled separately and will increase the traceability of the individual steps of the net execution.

**Figure 3.39** Basic idea of policy re-enactment exemplified for SoD constraints

Besides the points of re-enactment and its encoding with Petri net elements, it is key to consider the bigger picture that takes all re-enactment points and scopes defined for a workflow into account. More precisely, the creation of Petri net elements that realize re-enactment (i.e., the creation of "re-enactment constructs") needs to consider the cancellation and enactment, as well as the fact that scopes may potentially be part of other scopes. Here, straightforward construction of the re-enactment encoding for each of these scopes could result in multiple constructions of re-enactment encodings that involve the same scope, so that parts of the re-enactment constructs would be built multiple times for the same user-task authorizations or constraints. On the one hand, in order to keep the modeling complexity as low as possible, unnecessary, redundant constructions must be avoided. On the other hand, such multiple constructions could interfere with each other in an unintended way and manipulate the overall re-enactment encoding. For example, based on an SoD place, as in Figure 3.39, if there were multiple cancellation constructs for the cancellation of the same SoD place, the firing of the cancellation transition would then depend on tokens in the cancellation control in both constructs. The cancellation would in turn depend on the triggering of both re-enactment points at the same time, which may not be the case in the control flow. Hence the construction of a re-enactment must be done in a way that preserves the initial net behavior and does not result in such unintended manipulations. Here, creating re-enactment constructs for each user-task authorization and each constraint separately may avoid this. Re-enactment points could then trigger these individual constructs according to their scope of tasks. However, then all net elements controlling each cancellation and enactment would entail a high modeling complexity. Therefore, the re-enactment encoding needs to consider the interdependencies between scopes as well. Analogously to the block structure of the workflow net—in particular, block-structured loops—the scopes of re-enactment relate to blocks. Hence besides demanding an appropriate position of the re-enactment points, it is reasonable to ensure that their scopes are block structured as well. Here, there arises the question of how the creation of the re-enactment construct can be used by multiple re-enactment points such that nested scopes can be re-enacted. Moreover, how must the creation of the re-enactment constructs take place in order to successively allow for nesting of all scopes according to the block structure?

**Figure 3.40** CEW re-enactment points

**Nesting of Re-Enactment Scopes:** Based on the block structure of the workflow, it is assumed that re-enactment scopes are nested only blockwise. Accordingly, Figure 3.40 extends the CEW workflow with re-enactment points and three scopes: *S*<sup>1</sup> = {*t*1, *t*2}, *S*<sup>2</sup> = {*t*3, *t*4}, and *S*<sup>3</sup> = {*t*1, *t*2, *t*3, *t*4, *t*5}. It can be observed that the scopes that are nested are proper subsets of larger scopes; for example, *S*<sup>3</sup> = *S*<sup>1</sup> ∪ *S*<sup>2</sup> ∪ {*t*5}. Figure 3.41 illustrates the structural idea of how a re-enactment of nested subscopes is embedded into the re-enactment of a scope. Here, the marked place - *p <sup>S</sup>* indicates the state in which re-enactment has been triggered. A completed re-enactment for a given scope is indicated by a complete circle in which the symbol of the scope is embedded, hat is, a marked place *p*. Accordingly, *t* finishes the re-enactment for scope *S*. Based on this, Figure 3.41 illustrates how to connect the "re-enactment construction" for a given re-enactment transition. For this, the "enter re-enactment" transition is extended by producing a token in each place of the re-enactment constructs for some subscope *Y* of *S*. Similarly, each place of the connected subscopes is connected to the "leave re-enactment" transition, hence the re-enactment is not allowed to be finished until after all parts of the scopes are finished. Thus all "re-enactment blocks" that are involved in the transitions of the regarded scope are embedded in parallel. Then placing tokens in the places that trigger re-enactment for their scopes initiates different cancellations and enactment blocks. Moreover, this construction allows for checking whether a block is already nested, namely, if - *<sup>t</sup> <sup>S</sup>* isn't the only incoming transition of the place - *p <sup>S</sup>*, that is, | • - *p <sup>S</sup>*| > 1. Analogously to the idea of cancellation and enactment, Figure 3.41 only the basic idea. In order to allow for higher modularity and clear execution steps, these steps will be formalized in a more fine-grained manner below.

**Creation of Re-Enactment Constructs:** There is not only the question of how to structure and nest blocks, but also how to conduct the creation of all the Petri net re-enactment elements so as to reflect and preserve the block structure. Analogously to the block structure, scopes can be seen as blocks that nest each other. A scope that nests another scope represents a superscope. A scope that is embedded in a larger scope represents a subscope. Again, depending on which scope is chosen to begin the creation of re-enactment constructs, a scope could be built before its subscope elements are built. The creation of a re-enactment construct for the subscopes either would result in multiple re-enactment constructs from the same policy parts or would require restructuring of the re-enactment constructs already created. To avoid such a cumbersome approach, a systematic procedure for building and connecting the scopes of re-enactment one after the other will be subsequently developed. Here, it is worthwhile to consider the effects of the block structure on the individual

**Figure 3.41** Nesting of re-enactment blocks in parallel

scopes—in particular, how they nest each other. The nesting implies that the nested scopes represent proper subsets of a superscope; for example, *S*<sup>3</sup> = *S*<sup>1</sup> ∪ *S*<sup>2</sup> ∪ {*t*5} (as indicated before). Obviously, the set of scopes over some set of workflow tasks represents a subset of the power set of these tasks, that is, *S* ⊂ *P*(*T* ). Here, the block structure of the affected models represents a subset of the standard partial order on the power set of *T* . For instance, the power set of the set of five tasks with the set of scopes *S* ⊂ *P*(*T* ) from Figure 3.40 highlighted in bold is

$$\begin{aligned} \mathcal{G}^{\beta}(T) &= \{\emptyset, \\ &\{t\_{1}\}, \{t\_{2}\}, \{t\_{3}\}, \{t\_{4}\}, \{t\_{5}\}, \\ &\{\mathtt{t}\_{1}, \mathtt{t}\_{2}\}, \{t\_{1}, t\_{3}\}, \{t\_{1}, t\_{4}\}, \{t\_{1}, t\_{5}\}, \{t\_{2}, t\_{3}\}, \\ &\{t\_{2}, t\_{4}\}, \{t\_{2}, t\_{5}\}, \{t\_{3}, t\_{4}\}, \{t\_{3}, t\_{5}\}, \{t\_{4}, t\_{5}\}, \\ &\{t\_{1}, t\_{2}, t\_{3}\}, \{t\_{1}, t\_{2}, t\_{4}\}, \{t\_{1}, t\_{2}, t\_{5}\}, \{t\_{1}, t\_{3}, t\_{4}\}, \\ &\{t\_{1}, t\_{3}, t\_{5}\}, \{t\_{1}, t\_{4}, t\_{5}\}, \{t\_{2}, t\_{3}, t\_{4}\}, \{t\_{2}, t\_{3}, t\_{5}\}, \\ &\{t\_{2}, t\_{4}, t\_{5}\}, \{t\_{3}, t\_{4}, t\_{5}\}, \{t\_{1}, t\_{2}, t\_{3}, t\_{4}\}, \{t\_{1}, t\_{2}, t\_{3}, t\_{5}\}, \\ &\{t\_{1}, t\_{2}, t\_{4}, t\_{5}\}, \{t\_{1}, t\_{3}, t\_{4}, t\_{5}\}, \{t\_{2}, t\_{3}, t\_{4}, t\_{5}\}, \\ &\{t\_{1}, t\_{2}, t\_{3}, t\_{4}, t\_{5}\}). \end{aligned}$$

It can be seen directly that only scopes of smaller cardinality, for example |*S*1| = 2, can be part of scopes of higher cardinality, for example |*S*3| = 5. Hence if a scope is nested in another scope, this automatically implies that its superscope must have a higher cardinality. For example, if a block of a task *t*<sup>1</sup> is nested in another scope, this scope must contain *t*<sup>1</sup> but also at least one additional element. Otherwise, it would constitute just the scope *t*<sup>1</sup> itself. Consequently, scopes with the same cardinality cannot be subsets of each other, that is, scopes cannot nest other scopes of the same cardinality. Moreover, the nesting excludes the possibility that some smaller scope is directly nested in multiple scopes of higher cardinality. (Equivalently, scopes of the same cardinality cannot nest the same subscope.) Also, a task cannot be directly nested in more than one scope of the next higher cardinality. For example, the scopes {*t*1, *t*2} and {*t*2, *t*3} would have the overlapping task *t*<sup>2</sup> and would not adhere to the considered block structure. Such overlapping scopes are problematic, since they could allow for re-enactment of a single scope to be triggered multiple times at once from different re-enactment points that involve the same subscope. If that were to happen, multiple tokens would be placed into the re-enactment construct, which would contradict the condition-event principle on which the safe SecANet encoding is built, diffuse the meaning of markings and the firing of transitions, and manipulate the intended behavior of the re-enactment constructs. Hence scopes may not overlap with other scopes. In case some scope contains a task of another scope, it must completely nest the scope in which this task occurs, hence a scope can be directly nested in only a single superscope. Such a superscope can then itself be embedded in a single scope of higher cardinality.

These considerations on the block structure, which manifest in the cardinality of scopes, will be useful in the construction of the policy re-enactment. Accordingly, the creation of re-enactment constructs will be built with increasing cardinality of scopes, that is, from the minimal to the maximal set of the family of sets *S*. For each cardinality, the corresponding re-enactment constructs are supposed to be created and potentially to nest smaller scopes. After the maximal sets of scopes have been considered, the creation of the re-enactment constructs is completed, hence all reenactment points will be flattened into the SecANet step by step.

#### **3.2.5.2 Flattening Policy Re-Enactment**

Algorithm 3.1 encodes the overall framework of policy re-enactment and controls the creation of the policy re-enactment constructs. Thereby, the order in which the re-enactment is encoded is given by the increasing cardinality of the scopes (see line 7).

#### **Algorithm 3.1** Policy Re- Enactment Framework(SecANet)

**Input:** (*NT A*+*C*, - *T <sup>S</sup>* ) The SecANet *NT A*+*<sup>C</sup>* resulting from Definitions 3.30, 3.31, and 3.32 and its re-enactment points - *T <sup>S</sup>* with *S* = {*S*1,..., *S*|*S*|} and *S* ⊆ *T* . **Output:** *NT A*+*C*<sup>+</sup> - *T <sup>S</sup>* The SecANet *NT A*+*C*<sup>+</sup> - *T <sup>S</sup>* encoding policy re-enactment. 1: *N* ← *NT A*+*<sup>C</sup>* 2: *<sup>i</sup>* <sup>←</sup> 1, with *<sup>i</sup>* <sup>∈</sup> <sup>N</sup>. *<sup>i</sup>* defines the cardinality of the scopes under consideration. 3: **repeat** 4: **for each** - *<sup>t</sup> <sup>S</sup>* <sup>∈</sup> - *T <sup>S</sup>* with |*S*| = *i* **do** 5: Create the net elements for - *t <sup>S</sup>* (i.e., a re-enactment transition whose scope *S* has cardinality *i*), and place them into the SecANet *N* by successively applying Definitions 3.67, 3.68, 3.69, 3.70, and 3.71. 6: **end for** 7: *i* ← *i* + 1 8: **until** *<sup>i</sup>* <sup>&</sup>gt; <sup>|</sup>*<sup>T</sup>* <sup>−</sup> - *T <sup>S</sup>* | *i* may not exceed the number of WF tasks. 9: **return** *N*

The subsequent definitions will relate to a re-enactment transition of a SecANet *N* that contains all re-enactment transitions and their corresponding scopes (as specified on line 5). The following is an overview of these definitions.

	- Cancellation and Enactment (Definition 3.69)
		- User-Task Cancellation and Enactment (Definition 3.70)
		- Constraint Cancellation and Enactment (Definition 3.71)

First, the basic Petri net elements that control the beginning and the end of reenactment for a certain scope will be created.

**Definition 3.67 (Creation of Re-Enactment Controls)** *Based on a reenactment transition* - *t <sup>S</sup> and its scope S, the re-enactment for S is controlled by placing the following net elements into the* SecANet *N, where*

$$N = \langle P \cup P\_S, \, T \cup T\_S, \, F \cup F\_S, \, m\_0 \rangle \text{ with}$$

As indicated before, it must be checked whether there are nested subscopes for the scope under consideration. Because of the incremental construction method, which is based on the increasing cardinality of scopes, it must be ensured that the block structure is gradually built into the re-enactment construct already created in *N*. Here, based on the re-enactment control created for each transition - *t <sup>S</sup>*, it must be checked whether its scope *S* involves other scopes.

**Definition 3.68 (Nesting of Re-Enactment Controls).** *Based on the reenactment control created for a transition* - *t <sup>S</sup> from Definition* 3.67*, for each place of N of the form* - *p <sup>Y</sup>* ∈ *P where Y* ∈ *S it must be checked whether its scope Y is a subset of the considered scope of S of* - *t S, that is, Y* ⊂ *S. Based*

<sup>14</sup> For better clarity and readability, the naming of the depicted nodes is simplified compared to their written notation; for example, the scope *S* is omitted in the naming of the transition.

*on the nesting defined in this definition, if* | • - *p <sup>Y</sup>* | > 1 *then Y is already embedded in another block. Since scopes may not be nested in more than one block, the construction described in this definition may be built only if* | • - *p <sup>Y</sup>* | = 1*. Then the scope Y is not only triggered by its corresponding re-enactment transitions* - *t <sup>Y</sup> but also controlled with the help of arcs pointing from the current scope S to* - *p <sup>Y</sup> and back, that is, the set of arcs of N is extended by* {*tSEnterCancellation* , - *p <sup>Y</sup>* ,*p*<sup>Y</sup> , *tSLea*v*eEnactment*}∪ *F. The figure below shows the graphical representation of this nesting of re-enactment controls:*<sup>15</sup>

In this way, the basic framework in which the cancellation and enactment of the specific policy parts can take place is built. In the next step, the construction that controls the cancellation and enactment for a specified scope of tasks is explained. It will be controlled by firing the respective "enter" and "leave" transitions for the cancellation and enactment. Accordingly, the subsequent Petri net construct will be the frame which is used to control cancellation and enactment.

**Definition 3.69 (Cancellation and Enactment).** *Let S be a scope of transitions, and let TScancel* = {*tSEnterCancellation* , *tSLea*v*eCancellation* } *and TSenact* = {*tSEnter Enactment*, *tSLea*v*eEnactment*} *be the sets of transitions in N that trigger cancellation and enactment, respectively. The cancellation*

<sup>15</sup> The scopes nested in the scope under consideration are triggered by the arcs containing - *p <sup>Y</sup>* . All subscope-related re-enactment constructs that are not already nested in other reenactment constructs are nested in parallel to the re-enactment construct of the scope under consideration.

*and enactment are controlled by adding the following net elements to the* SecANet *N, where N* = -*P* ∪ *PS*, *T* ∪ *TS*, *F* ∪ *FS*, *m*0 *with*

*PS* = {*pS*ToCancel, *pS*CancellationRunning , *pS*CancellationPerformed , *pS*Canceled , *pS*ToEnact, *pS*Enacted },

*TS* = {*tS*StartCancellation , *tS*ProceedWithCancellation , *tSFinishCancellation* , *tS*Enact},

*FS* = {*tS*EnterCancellation , *pS*ToCancel,*pS*ToCancel, *tS*StartCancellation , *tS*StartCancellation , *pS*CancellationRunning ,*tS*CancellationPerformed , *pS*ProceedWithCancellation , *tS*ProceedWithCancellation , *pS*CancellationRunning ,*pS*CancellationRunning , *tS*FinishCancellation , *tS*FinishCancellation , *pS*Canceled ,-,*pS*Canceled , *tS*LeaveCancellation ,*tS*EnterEnactment, *pS*ToEnact, *pS*ToEnact, *tS*Enact,*tS*Enact, *pS*Enacted ,*pS*Enacted , *tS*LeaveEnactment}.

*The figure below shows the graphical representation of these net elements:*

The "cancellation running" and "cancellation performed" places will be the incoming and outgoing places, respectively, for each transition that will actually allow canceling (i.e., consuming) of leftover tokens, which will be illustrated in Definitions 3.70 and 3.71. Moreover, if all involved places that indicate a completely cleared policy construct are marked, they are supposed to enable the transition that produces a token in a place that indicates that the cancellation is completed. The enactment-related Petri net elements will then need to put only the initial tokens into the places of the corresponding policy net elements.

**Figure 3.42** DMV example with re-enactment, cancellation, and enactment controls

The example in Figure 3.42 applies the definitions given so far to the re-enactment transition in a DMV SecANet. Since up to now only the control flow of the DMV example is affected by the re-enactment elements, the SecANet constructs that encode user-task authorization and the SoD constraints are omitted for better readability.

The constructed re-enactment-related Petri net elements now constitute the complete framing in which the actual re-enactment is supposed to occur. The next definitions will connect the elements of this frame with the policy-related parts of the SecANet—in particular, with the cancellation and enactment of user-task authorization and constraints, respectively.

Given a user-task authorization, indicated by its initially marked place *pt*<sup>−</sup> from a SecANet, the cancellation is as follows: First, a place that indicates whether the task has been executed, that is, an outgoing place *pt* of the transition *t*, is added. Thus it is now possible to cover all three possible states that can occur in the course of a user-task assignment by the three places*t*−, *t*+, and *pt* . As previously observed, in the course of the language-related initial and final markings, and because of the given sequential order, it is always the case that only one of the three places can be marked. Here, for each such state a cancellation transition is needed. All three cancellation transitions have the same outgoing place, indicating that all places related to the user-task authorization are empty. The following definition represents the general encoding of how to clear all possible token distributions in a user-task authorization construct and how to enact it. Analogously to the nesting, it will be checked whether this construct already exists, based on the existence of incoming transitions for the place *p*<sup>−</sup> that indicate user-task unassignment. If such incoming transitions exist, this means that the corresponding user-task construct already exists and is part of another scope in which its re-enactment is supposed to be nested.

**Definition 3.70 (User-Task Cancellation and Enactment).** *For each t* ∈ *S, let Pt*−+ = {*pt*−, *pt*+} *be a set of pairs of the user-task authorization of the* SecANet*, where Pt*−+ ⊆ *P*˙ *T A. If* •*pt*<sup>−</sup> = ∅*, the subsequent elements are added to the* SecANet *N to cancel the state of the user-task authorization and to enact it. Otherwise (if* |*Pt*−| > 0*), the construct has already been added in a nested scope. Specifically,*

*N* = -*P* ∪ *PS*, *T* ∪ *TS*, *F* ∪ *FS*, *m*0 *with*

*PS* = {*pt*Executed , *put*Canceled },

*TS* = {*t*Cancel*t*<sup>−</sup> , *t*Cancel*t*<sup>+</sup> , *t*Cancel*<sup>t</sup>* Executed },

*FS* = {*pt*−, *t*Cancel*t*<sup>−</sup> ,*t*Cancel*t*<sup>−</sup> , *put*Canceled , *pt*+, *t*Cancel*t*<sup>+</sup> ,*t*Cancel*t*<sup>+</sup> , *put*Canceled ,*t*, *pt*Executed ,*pt*Executed , *t*Cancel*<sup>t</sup>* Executed ,*t*Cancel*<sup>t</sup>* Executed , *put*Canceled , *pS*CancellationRunning , *t*Cancel*t*<sup>−</sup> ,*t*Cancel*t*<sup>−</sup> , *pS*ProceedWithCancellation ,*pS*CancellationRunning , *t*Cancel*t*<sup>+</sup> ,*t*Cancel*t*<sup>+</sup> , *pS*ProceedWithCancellation ,*pS*CancellationRunning , *tCancelt* Executed , *tCancelt* Executed , *pS*ProceedWithCancellation ,*put*Canceled , *tS*FinishCancellation ,*tS*Enact, *pt*−}

*The figure below shows the graphical representation of these net elements:*<sup>16</sup>

<sup>16</sup> For better clarity and readability, the naming of the depicted nodes is somewhat simplified compared to their written notation; for example, the scope *S* is not subscripted.

It is important to note that, based on the re-enactment construction, user-task transitions could occur in a firing sequence in which they are not followed by their respective tasks. For the interpretation of the encoding, therefore, it is important to note that only the last user-task assignment before the corresponding task execution encodes the actual user that executes the task.

Regarding constraints, for a given constraint place *C* in a SecANet, the cancellation is as follows: First, a complement place for *C* is created. Then each outgoing transition from the constraint place *C* needs to be connected to the new complementary place as its incoming transition. Moreover, a new transition that has the constraint place as the incoming place and the complementary place as the outgoing place is created. Thus if during workflow execution the constraint is taking effect, this state is captured by the complementary place. Otherwise, the cancellation transition may erase leftover tokens during execution of the loop. Since both of these cases result in an empty constraint place *C*, only one place is used to document this. For example, Figure 3.44 depicts such a cancellation construct for an SoD place. Hence a marked complementary place represents the state in which the corresponding constraint place is empty, which may result from the application of the constraint in the course of a user-task assignment or may indicate cancellation.

**Definition 3.71 (Constraint Cancellation and Enactment).** *Let Cutk tl be a constraint place abstracting from SoDu <sup>j</sup> tk tl or BoDu <sup>j</sup> tk tl . For each Cutk tl where tk* , *tl* ∈ *S and tk* = *tl , the cancellation of the state of the constraint enforcement and its enactment is provided by adding the net elements indicated below. Again, only if* • *Cutk tl* = ∅ *are the subsequent elements are added to the* SecANet *N to cancel the state of the constraint and to enact it. (Otherwise, i.e., if* | • *Cutk tl* | > 0*, this indicates that the construct has already been added in a nested scope.) Specifically,*

*N* = -*P* ∪ *PS*, *T* ∪ *TS*, *F* ∪ *FS*, *m*0 *with*

*PS* = {*pCutk <sup>t</sup> <sup>l</sup>* Complement},

*TS* = {*t*Cancel*Cutk <sup>t</sup> l* },

*FS* = {{*tut*, *pCutk <sup>t</sup> <sup>l</sup>* Complement|*tut* ∈ *C*• *utk tl* } ∪ {-*Cutk tl*, *t*Cancel*Cutk <sup>t</sup> l* ,*t*Cancel*Cutk <sup>t</sup> l* , *pCutk <sup>t</sup> <sup>l</sup>* Complement,*p*CancellationRunning, *t*Cancel*Cutk <sup>t</sup> l* ,*t*Cancel*Cutk <sup>t</sup> l* , *p*ProceedWithCancellation,*pCutk <sup>t</sup> <sup>l</sup>* Complement, *tS*FinishCancellation ,*tS*Enact,*Cutk tl*}

*The figure below shows the graphical representation of these net elements:*<sup>17</sup>

<sup>17</sup> *C*• denotes all user-task transitions affected by a constraint. After all the transitions are connected as incoming transitions of *Cutk tlComplement* , the last step is to add the cancellation transition as an outgoing transition of *C* and an incoming transition of *Cutk tlComplement* .

Based on Algorithm 3.1 and the definitions embedded therein, it is now possible to fully construct the net elements that provide policy re-enactment. Figure 3.43 illustrates the policy re-enactment for the example DMV SecANet. It must be admitted that, for this simple example, the effort for re-enactment seems rather disproportionate. However, this is considered as the "price to pay" to obtain a general and clear encoding for larger nets as well. Here, based on the systematic, incremental construction, the elements of the control constructs increase linearly with the number of re-enactment points and their scopes. Although the overall construct could be simplified (e.g., see Figure 3.39), the aim has been to keep the construction clean and as clearly arranged as possible. Moreover, this general modular construction will allow further usage in other respects (see Section 3.2.6.3). Also, the concept of re-enactment points offers the possibility for refinement. Although re-enactment has applied thus far to tasks in general, it could be refined in terms of policy type or users. In order to prevent multiple access by the same person during particularly critical activities, for example, one could exclude constraints from re-enactment and retain only the SoD constraints that have already been put into effect.

**Figure 3.43** DMV loop and re-enactment

**Comprehensive SecANet Example of the Collateral Evaluation Process:** To show the applicability of the flattening for a larger comprehensive net structure involving cycles, the example of a workflow net for collateral evaluation in Figure 3.20 which is based on the BPMN model that involves release points from Figure 3.19 will be used. The SoD and BoD constraints are noted right in the BPMN

**Figure 3.44** SoD cancellation example

**Figure 3.45** User-task assignment

model. The release points (see *o*1, *o*2, *o*3) allow these constraints to be considered in the scope of each loop separately. In order to illustrate that the SecANet encoding is applicable to different models, the intention is to leave the model as is and interpret the release points as re-enactment points for their corresponding scopes, where *So*<sup>1</sup> = {*t*1, *t*2}, *So*<sup>2</sup> = {*t*3, *t*4}, and *So*<sup>3</sup> = {*t*1, *t*2, *t*3, *t*4, *t*5}. Figure 3.45 depicts an example of a corresponding user-task assignment. According to the mapping in Figure 3.18 from Dijkman et al. [78], the BPMN model is first transformed into a P/T net. Then the user-task assignment, the two SoD constraints, and one BoD constraint are flattened into the net according to the theory presented above. Finally, the policy re-enactment constructs for the release points are added. Figure 3.46 depicts the resulting SecANet, with different shades highlighting the individual parts of the net. It is displayed to give an impression of the overall system that results from the flattening. To increase readability, the policy re-enactment considers only simplified re-enactment constructs without user-task cancellation (as, for instance, in Figure 3.39). As previously indicated, if all the tasks are executed, user-task cancellation can be neglected for re-enactment, since the tokens in all user-task assignment places of the form *pt*<sup>−</sup> and *pt*<sup>+</sup> are consumed in the course of execution. However, this net also contains obstructions, which will be treated in more detail in the subsequent chapters, where approaches that solve obstructions based on the presented flattening are presented.

#### **3.2.6 SecANet Analysis: Satisfiability and Obstructability**

Based on Definitions 3.30, 3.31, and 3.32 and Algorithm 3.1, a SecANet can encode a policy-awareWF-net with a comprehensive block structure involving cyclic, exclusive, and parallel paths. Moreover, based on Definitions 3.33 and 3.34, markings that encode obstructed and satisfiable firing sequences are provided. Thus a SecANet can encode security properties and can be interpreted with regard to satisfiability and obstructability. Specifically, the related liveness security property of process completion can be checked by considering all possible execution sequences (or events), which in the end constitute sequences (or traces) that may or may not have that property. As previously illustrated, satisfiable execution sequences may reach markings that contain *po*, that is, the output place of the initial WF-net is marked. If this occurs, it means that there is a full firing sequence (equivalently, that there is a valid plan) such that the workflow is satisfiable. On the other hand, obstructed execution sequences reach terminal markings that do not contain the output place *po*. Hence the liveness security property of process completion can also be checked by examining whether final markings (or states) that either involve *po* or not are reachable.

Hence satisfiability and obstructability are both concerned with reachability in the first place. Satisfiability is concerned with whether there is a marking greater than *po* which is reachable in a SecANet. Obstructability is concerned with whether there is a marking that neither contains *po* nor enables any further transitions. The most basic method for determining satisfiability and reachability would be to play the token game until a desired marking is reached, that is, until the net reaches the obstruction marking or the marking containing *po*. While this is a feasible endeavor for the DMV example, larger net structures demand more systematic approaches. Here, the most straightforward way would be to build the marking graph of the net. The reaching of the end marking would then resolve the workflow as satisfiable, and the reaching of a terminal marking without *po* would reveal an obstructed state. Moreover, as elaborated at the beginning of this chapter, there are many additional techniques which may be used to examine reachability more efficiently. Those techniques will also be highlighted in Chapter 4, which introduces the so-called marking equation and uses integer linear programming techniques to answer questions related to reachability. Next, it is shown how to transform a SecANet in such a way that deadlock detection and liveness analysis can be applied to it, the main objective being to relate the notion of soundness to the SecANet encoding. Thus the analysis of SecANet soundness will subsume the analysis of satisfiability and obstructability.

**Figure 3.46** The collateral evaluation workflow (cf. Figure 3.20) with the user-task flattening (cf. Figure 3.23a), the SoD or BoD flattening (cf. Figure 3.23b), and re-enactment (bright nodes as in Figure 3.39)

#### **3.2.6.1 SecANet Soundness**

A sound SecANet is considered to be satisfiable and obstruction-free. For a consistent evolution of existing terminology and definitions from the literature, the notion of SecANet soundness will be built upon the definitions of soundness of a workflow net. As mentioned in Section 3.1.2.4, a sound workflow represents a workflow that is able to reach the output place from every reachable marking (i.e., it has the "option to complete," meaning that every task is involved in the processing of a case). Moreover, all of its tasks need to be executable at least once (referred to as the "no dead transitions" condition). Finally, when the output place is marked, no other places are supposed to be marked (denoted as "proper completion"). From the perspective of access control, an obstruction is also a case that cannot be processed to its completion because the policy is blocking further progress. Satisfiability relates to the executability of each task. If a certain workflow task is not executable in any possible execution sequence, the workflow path that involves this workflow task is not satisfiable. Here, this means that the policy does not allow the firing of a user-task assignment that would enable the regarded workflow task. Hence in order to check satisfiability and obstructability, the notion of "soundness" of a workflow will be tailored to soundness of a SecANet. Since, as previously elaborated, it cannot be ensured that the marking in *po* is the only marked place left after a SecANet execution, the "proper completion" property will be neglected for the moment.

The subsequent interpretation of the "option to complete" and the "no dead transitions" property will assume that the workflow for which a SecANet is created is block structured and sound (cf. Section 3.1.2.4). This implies that the workflow net within the SecANet fulfills the "option to complete" and has no dead transitions. Thus it suffices to analyze whether a sound workflow net is still sound in the context of the SecANet encoding surrounding it. If the SecANet encoding cannot fulfill the conditions or soundness, the reason for this has to lie in the net elements created in the course of the flattening that encode the policy.

Similarly to the definition from workflow soundness, the "option to complete" is supposed to check whether it is possible to reach a marking that involves *po*. Thus the "option to complete" condition for a sound SecANet encodes obstruction-freeness for every possible execution sequence (or case). If a case is not completable, it represents an obstructed case, that is, the "option to complete" of the initially sound workflow is no longer fulfilled in the SecANet.

As examined before, obstructions describe individual process executions (or cases) that are not completable. They may occur in satisfiable or unsatisfiable workflows. If all possible cases for a specific path of workflow tasks result in an obstruction (i.e., the path is not completable for any of the possible user-task assignments), this means that the path is not satisfiable at all. Hence if the "option to complete" is not fulfilled at least once for a certain path, the transitions that are always blocked never become enabled, that is, they are dead. Thus the question of whether a workflow is satisfiable at all can be answered by checking for dead workflow tasks in a SecANet. Put differently, if all WF tasks are simply live (equivalently, quasi-live), the workflow is satisfiable. For workflows with sequential or parallel paths, a dead task then implies that the entire workflow is unsatisfiable. In workflows with exclusive branching, a dead task means that only the path on which this task occurs is unsatisfiable. They may also include satisfiable executions. Regardless of the actual structure of the workflow, therefore, the SecANet workflow will be considered unsatisfiable as soon as there are dead workflow tasks, since the policy does not allow full execution of all possible paths given by the initially sound workflow. It is assumed that the "no dead transitions" property for a SecANet has to hold only for the workflow tasks, not for user-task assignments (which are all simply live based on the initial marking) or for transitions that serve only functional routing purposes. This is because, on the one hand, the original "no dead transitions" condition concerns only the workflow tasks. On the other hand, the question of satisfiability is ultimately also answered by looking at the workflow tasks, namely by determining whether a task is executable or not.

A sound SecANet is thus defined to be obstruction-free and satisfiable if it fulfills the "option to complete" and has "no dead transitions." These two conditions will

**Figure 3.47** SecANet that fulfills the option to complete, with dead transition *t*<sup>2</sup> and implicit gateways

directly allow observing the connections and implications between satisfiability and obstructability in the context of a specific net. The subsequent definition will adapt the definition of the properties from workflow soundness (cf. Definition 3.72) to the SecANet encoding. Based on the assumption that the underlying workflow net is sound, a SecANet is sound if and only if the following two requirements are satisfied:

**Definition 3.72 (Soundness of a SecANet)** *A* SecANet *N with workflow input place i and workflow output place o is sound if the following conditions are met:*


In the example, the previously identified obstruction marking in Figure 3.24 indicates that it is not always possible to complete the DMV SecANet workflow (i.e., the "option to complete" is not fulfilled). However, the DMV SecANet does not contain dead WF transitions, which underlines its previously identified satisfiability. Here, removing *u*<sup>2</sup> from the user-task permissions for *t*1, for example, would render the last WF-task(*t*2) dead because the workflow would not be satisfiable.

In this regard, Figure 3.47 illustrates the potential pitfalls of the interpretation and interconnections between the conditions of SecANet soundness. Supposedly small differences in the interpretation of workflows on the Petri net level can impact the obstructability analysis. At the same time, the Figure underlines the importance of exactly how gateways are modeled as well as how rather coarse-grained modeling may cause a loss of important security-related information. Figure 3.47 depicts a SecANet that has the option to complete the workflow but contains a dead transition, *t*2. The ensuing interpretation that the workflow is obstruction-free but not satisfiable would, however, contradict the identified relationships between satisfiability and obstructability. In this regard, a closer look at the net reveals that it implements forks and joins in a rather reduced, implicit way. For instance, firing transition *t*<sup>1</sup> or*t*<sup>5</sup> at the beginning of the net determines which path to take and, at the same time, executes the actual task following this decision. If transition *t*<sup>1</sup> is obstructed, the other path (the one that starts with *t*5) can be chosen instead. Because of the unconstrained user-task assignment represented by *tu*4*t*<sup>5</sup> , the latter is a path that obviously cannot obstruct. For this reason, the obstruction does not block the process. However, it still reduces the option of which path to choose and restricts the behavior of the initial workflow. Hence in order to have full control over the net in a fine-grained way and avoid such "hidden" obstructions, a workflow has to be modeled according to the block structure and the common transformation from BPMN into Petri nets (cf. Figure 3.18). Each fork and join is supposed to be resolved as a separate construct that does not involve tasks. Figure 3.48 encodes the workflow with explicit joins and forks according to the common transformation of gateways into Petri nets (e.g., from BPMN). Checking the net in Figure 3.48 for the two soundness conditions reveals the dead transition *t*<sup>2</sup> too, but the related obstructions at transitions *t*<sup>1</sup> and *t*<sup>2</sup> come to light as well. This is thus consistent with the identified implications between the "option to complete" and "no dead transitions" condition and their relations to obstructability and satisfiability. First, the decision to take a certain path has to be made irrespective of any user-task assignment. After this decision, a potential obstruction cannot be circumvented. Thus potential constellations in which certain tasks cannot be performed because of authorization constraints cannot be undermined in such a way that weak spots of the policy can be identified again. Therefore, the workflow involved in a SecANet must explicitly encode forks and joins for parallel and exclusive gateways that do not depend on any user-task assignments of the policy encoding. The user-task encoding in a SecANet must be created only for actual workflow tasks that are supposed to be executed by users. Then an unsatisfiable workflow cannot be obstruction-free, since the explicit modeling of gateways implies that it must be possible to explicitly choose the path that involves the dead transition, and thus to obstruct the execution.

Hence a workflow may have "no dead transitions" and no "option to complete," so that it is satisfiable but obstructive, or it may have "no dead transitions" and the "option to complete," in which case it is satisfiable and obstruction-free. A dead transition means that, somewhere on the path before the transition, there is an obstruction that does not allow the transition to be enabled. Hence in a SecANet the option to complete cannot be fulfilled in the face of dead transitions. Either there is an obstruction that directly causes the workflow transition to be dead, or there may be an obstruction at some earlier point in the execution that deadens all succeeding tasks. In regard to the latter, and regardless of whether a user can be assigned to a task or not, the control-flow token needed to enable the workflow task would then be missing for the succeeding tasks. A SecANet that neither has the option to complete nor has no dead transitions is neither satisfiable nor obstructionfree.

**Figure 3.48** SecANet that does not fulfill the option to complete, with dead transition *t*<sup>2</sup> and explicit gateway modeling

#### **3.2.6.2 SecANet Reversibility and Deadlock Analysis**

Both of the soundness conditions can again be represented as typical questions of reachability. "No dead transitions" asks if there is a transition that is not fireable from any reachable marking, while "option to complete" asks whether the final marking is reachable from any reachable marking. Because of the structural complexity of a SecANet, which, as previously explained, belongs at least to the class of asymmetric choice nets, it may be intractable to make a decision on its soundness [7, 136]. In contrast to reachability, as elaborated before, the computation of liveness as well as the identification of deadlocks can potentially be done more efficiently.

In a SecANet deadlocks are used to indicate the two crucial states. A satisfiable full firing sequence reaches a deadlock marking that contains *po*. A SecANet that encodes an obstructed execution reaches a deadlock marking without *po*. Thus the idea is to exclude from deadlock analysis the desirable end marking that encodes process completion and contains *po*. This is done by allowing the end marking to restore the initial marking, so that the net becomes reversible. Thus similarly to the WF-net extension related to the investigation of the strong-connectedness of a WF-net in Definition 3.22, an additional transition that connects the output place with the input place needs to be added. Since the reaching of the output place can no longer represent a deadlock, a deadlock is then supposed to indicate an obstruction. In a sense, the "option to complete" can thereby be "included" in the structure of the net. This inclusion allows searching for deadlocks beyond the desired deadlock of the marked output place. In such an extended net, the identification of deadlocks then becomes synonymous with the search for obstructions, thereby allowing for the use of typical existing methods for deadlock analysis—for example, checking for the siphon/trap property (cf. Definition 3.15 and Definition 3.16).

**Figure 3.49** Obstructability analysis exemplified with deadlock analysis (siphon/trap)

Because of the simplicity of the DMV SecANet example, it can be used to illustrate the intended extension, which is depicted in Figure 3.49. It is realized by adding a transition *t*∗ whose outgoing transition is the input place of the SecANet. It can now be reset to its initial marking by firing *t*∗. Moreover, *tstart* is added to enact the policy. Now, the siphon-trap property can be analyzed to identify deadlocks within the extended net, that is, whenever each siphon contains a trap the net is deadlock-free. The siphons and traps for the extended DMV SecANet are indicated with different-shaded bars. Without the extension, the siphons and traps would trivially be the source and sink places, respectively. Hence it can be observed that, concerning the workflow net and its user-task authorization, each siphon contains a trap. The related siphons and traps are completely in cover (which is highlighted by the dashed lines). However, the siphon that involves the SoD place does not contain the trap that contains the SoD place. The SoD-related trap encompasses all elements of the siphon but additionally contains *po* and *p*3. Based on this observation, it can be checked whether the SoD-related siphon can indeed become empty, namely if there is a marking *m* where *m*(*p*0) = 0 and *m*(*p*3) = 0. This is just the case with the obstruction marking. The trap property is fulfilled here too, because either place of the SoD-related trap (*p*<sup>1</sup> or *p*3) is still marked. Moreover, the extended example SecANet could be used to assess the liveness of the extended net, and hence check its soundness as well. Liveness checks typically first check for no dead transitions, and then check whether each transition is reachable from some reachable marking. If there are no dead transitions and the option to complete is fulfilled, each transition can be reached by any transition in the extended net, that is, the entire net is live.

As for the marking that contains the output place, it is important to note that the example net has an advantage in regard to deadlock and liveness analysis: As soon as the output place of the workflow is marked by a token, all other places of the example SecANet are empty. However, this is usually not the case in a SecANet. For example, in case there was another user authorized for both tasks, one of the SoD places would inevitably remain marked at the end of execution. Therefore, for a SecANet in general, before the net would be reinitialized with its initial marking, care must be taken to ensure that all places are empty again. Otherwise, leftover tokens could manipulate the results of the deadlock or liveness analysis. This can be achieved by introducing an additional construction, which uses the re-enactment constructs introduced in Section 3.2.5. If, at the end of execution, eventually only *po* is marked, that is, it is properly completed, this will then allow for an easy transition from this place directly to *pi* through a single transition *t*∗.

#### **3.2.6.3 SecA-WF-Net: Security-Aware Workflow Net**

While thus far only the "option to complete" and "no dead transitions" conditions could be related to a SecANet, the modular definition of the re-enactment constructs will subsequently allow for fulfilling the "proper completion" property as well. Since these three conditions exactly constitute the soundness of a WF-net, the SecANet will be extended to a so-called SecA-WF-Net, which represents a general way to extend a SecANet that contains the SecANet encoding as well as a WF-net structure. Moreover, with the help of the additional transition *t*∗, a SecA-WF-Net can then easily be extended in order to use it for the analysis of deadlocks or liveness.

Figure 3.50 depicts this overall frame of a SecA-WF-Net and how it is supposed to encapsulate a SecANet. It places the SecANet into a further frame that is supposed to enact and cancel the entire policy. The workflow structure demands that there be only one input place and one output place, and that the input place be the only marked place in the initial marking. Therefore, the enactment construction from before is used here to generate the initial tokens of a SecANet based on the initially marked source place *pi* . Moreover, in order to allow for "proper completion" the final cancellation construct of the re-enactment modeling above can now be used to

**Figure 3.50** SecA-WF-Net encapsulation and extension with *t*∗

reach the final marking in which only *po* is marked. Figure 3.50 also indicates the optional additional transition *t*∗ that allows for extension of the net in order to use it for deadlock or liveness analysis. This extension makes the net reversible, since the SecANet system can then get initial settings after it is executed, that is, the initial marking *m*<sup>0</sup> is reachable from every marking of [*m*0 (cf. Definition 3.14).

In order to allow for enactment and cancellation of the entire policy, two different cases must be considered. The first is the possibility that there already exist re-enactment constructs, at least for parts of the policy. Similarly to the re-enactment construction above, here again creation of multiple enactments or cancellation constructs must be avoided. Therefore, all places that trigger and document enactment and cancellation need to be connected to the respective "enter/leave enactment" transitions and cancellation transitions, respectively. However, the existence of reenactment points does not mean that their scopes cover all WF tasks. It could even be the case that the WF-net of the SecANet contains no re-enactment points. Hence for all WF tasks that are not covered by re-enactment constructs, the corresponding construct needs to be created for the respective policy parts. If the SecANet contains no re-enactment points, the construct will need to be created for the entire policy. The modularity of the re-enactment constructions introduced before allows for simply re-using the existing re-enactment definitions for the given sets of enter/leave enactment transitions and cancellation transitions, respectively. Accordingly, the subsequent definition is supposed to generate the workflow structure surrounding a SecANet in order to obtain a SecA-WF-Net.

**Definition 3.73 (WF-Structure Generation and SecA-WF-Net)** *Let N be a* SecANet *that contains a WF-net with an input place pi and an output place po, and let S be its scope involving all WF tasks. In order to control the enactment and cancellation of the policy for the set of all WF tasks S* ⊆ *T according to the WF structure, the following net elements are added to the* SecANet *N, where N* = -*P* ∪ *PS*, *T* ∪ *TS*, *F* ∪ *FS*, *m*0 *with*

*PS* = {*pEnacting Policy* , *pPolicyEnacted* , *pExecutionCompleted* , *pCanceling Policy* },

*TS* = {*tSEnter Enactment*, *tSLea*v*eEnactment*, *tSEnterCancellation* , *tSLea*v*eCancellation* },

*FS* = {*pPolicyEnacted* , *tPost I nput Place*|*tPost I nput Place* ∈ *p*• *i* } ∪ {*tPreOutput Place*, *pExecutionCompleted* |*tPreOutput Place* ∈• *po*} ∪ *pi*, *tSEnter Enactment*,*tSEnter Enactment*, *pEnacting Policy* ,*pEnacting Policy* , *tSLea*v*eEnactment*,*tSLea*v*eEnactment*, *pPolicyEnacted* ,{*pExecutionCompleted* , *tSEnterCancellation* ,*tSEnterCancellation* , *pCanceling Policy* ,*pCanceling Policy* , *tSLea*v*eCancellation* ,*tSLea*v*eCancellation* , *po*}*, and m*<sup>0</sup> = {*pi*} *(i.e., the initial markings of all policy encodings are set to 0).*

*Note that* {*pPolicyEnacted* , *tPost I nput Place*|*tPost I nput Place* ∈ *p*• *i* } *is supposed to take over the initial outgoing arcs of pi , and* {*tPreOutput Place*, *pExecutionCompleted* |*tPreOutput Place* ∈• *po*} *is supposed to take over the initial incoming arcs of po, where now p*• *<sup>i</sup>* = {*tSEnter Enactment*} *and* •*po* = {*tSLea*v*eCancellation* }*. The figure below shows the graphical representation of these net elements:*

*Based on this, all enactment and cancellation places are connected with the enter/leave enactment and cancellation transitions, where the set of arcs of N is* {*tSEnter Enactment*, *pYT oEnact*,*pYEnacted* , *tSLea*v*eEnactment*,*tSEnterCancellation* ,

*pYT oCancel*,*pYCanceled* , *tSLea*v*eCancellation* |*pYT oEnact*, *pYEnacted* , *pYT oCancel*, *pYCanceled* ∈ *P*, *Y* ⊆ *T* } ∪ *F*. *The figure below shows the graphical representation of this enactment and cancellation of the different scopes for which there are re-enactment constructs in N :*

*For the set of WF tasks for which there is no enactment and cancellation place, that is, the scope* {*S*− *pYEnacted* <sup>∈</sup>*<sup>P</sup> <sup>Y</sup>* <sup>|</sup>*<sup>Y</sup>* <sup>⊆</sup> *<sup>T</sup>* }*, the re-enactment-related net elements need to be created and added to N by successively applying Definitions* 3.69*,* 3.70*, and* 3.71*, which results in the* SecA-WF-Net *N.*

**Figure 3.51** DMV with loop and WF structure

The example in Figure 3.51 illustrates the SecA-WF-Net of the DMV SecANet. Again, similarly to the loop and re-enactment constructs, the workflow-structuregenerating construction is intended only to provide the structure of a WF-net and, at the same time, preserve the given functionality and encoding of a SecANet. Hence again, the intention in these constructions is that the related transitions could be set to silent, and yet the basic behavior, meaning, and interpretation of the SecANet would remain. Based on this workflow-structuredness, the soundness of a SecA-WF-Net can now be defined in relation to all three workflow soundness conditions. In addition to SecANet soundness, now the "proper completion" condition can also be included. In a SecA-WF-Net, "proper completion" means the extinction of all tokens in all places except the token in *p*0. Accordingly, the soundness of a SecA-WF-Net that contains a sound workflow net can be defined.

**Definition 3.74 (Soundness of a SecA-WF-Net)** *A* SecA-WF-Net *N with input place i and output place o is sound if the following conditions are met:*


Analogously to SecANet soundness, the soundness of a SecA-WF-Net then implies obstruction-freeness and satisfiability. For the extension of the SecA-WF-Net, the transition *t*<sup>∗</sup> is added as the outgoing transition of *po* and as the incoming transition of *pi* , hence there are two additional arcs, *po*, *t*∗ and *t*∗, *pi* (as indicated in Figure 3.50). The extended SecA-WF-Net can be used to check for deadlockfreeness or liveness of the workflow tasks. Analogously to the findings in [7], a SecA-WF-Net is sound if the extended SecA-WF-Net is live and bounded. Since the boundedness of a SecANet—specifically, its safeness—has been considered in all modeling steps so far, a SecA-WF-Net is assumed to be safe as well. A SecA-WF-Net that is not bounded violates the SecANet encoding and is not interpretable as such. Moreover, it is assumed that the WF-net encapsulated in a SecANet is a sound (and safe) workflow net.

Hence in order to determine the soundness of a SecA-WF-Net, first and foremost its liveness has to be determined. It is important to note that so far, liveness could be considered only for the actual workflow tasks. Moreover, a SecANet can contain cancellation transitions that never become enabled (i.e., they are dead). For example, the cancellation of a user-task assignment may never require the cancellation of the unassigned place *pu*<sup>−</sup> or the assigned place *pu*+, since the corresponding task is always executed. In contrast to that, liveness of the overall net results from the fact that the net has no dead transitions, that is, every transition is live. This means that every transition of a net can be infinitely enabled through some feasible sequence of firings from any marking in [*m*0 (cf. Definition 3.11). Figure 3.52 illustrates how a SecA-WF-Net could be extended to allow checking for the liveness of the entire net. Thus methods of analysis of workflow soundness could be applied to SecANet soundness more easily. The liveness of the extended SecA-WF-Net could then be checked with no restrictions and without having to consider workflow tasks only.

**Applicability of Reachability, Deadlock, and Liveness Analysis:** A SecA-WF-Net can be analyzed by applying methods from WF-net-related analysis and tools examining WF-net soundness—or, more generally, from reachability analysis. Moreover, the extended SecA-WF-Net allows the use of rather efficient methods that investigate the liveness of its workflow tasks as well as the deadlock-freeness of the entire net. Thus similarly to WF-nets, an extended SecA-WF-Net allows for the use of standard Petri-net-based analysis tools to decide its soundness [7]. For example, off-the-shelf model checkers can be used to analyze the liveness of its workflow tasks.

#### **3.2.7 Experimental Evaluation**

This section will demonstrate the applicability of Petri net analysis tools to the SecANet approach and compare the results to a typical existing approach for solving the workflow satisfiability problem (WSP). The SecANet model will be used to show how Petri net tools can be applied to examine obstructability as well. Thus it will be possible to determine SecANet soundness and draw potential benefits from using Petri nets to analyze satisfiability and obstructability.

Since it is difficult to acquire real-world WSP instances [48, 206], the randominstance generator described by Cohen et al. [48] was adapted in order to obtain instances of workflows and their policies. The generator considers a number of tasks *t*, a number of users *u*, a number of SoD constraints *s*, and a random-generator seed value. Here, since WSP instances usually do not contain exclusive or cyclic paths (cf. Chapter 2), each instance also requires that all tasks be performed in order to complete the workflow execution. Therefore, for the sake of simplicity, the *t* tasks of each instance are assumed to be performed in sequential order. For each user, the generator creates a uniformly random authorization list *T A*(*u*)such that the number of permissions per user, <sup>|</sup>*T A*(*u*)|, is selected uniformly from {1,..., *<sup>t</sup>* } at random. It also generates *s* distinct not-equals constraints uniformly at random [48]. Then for these instances the SecANet is generated according to the definitions in Section 3.2.2. Note that the WSP instance generator does not explicitly consider BoD constraints. Although the SecANet encoding allows the encoding of BoD constraints, for purposes of comparability, BoD constraints will not be considered here. As indicated before, SoD constraints are sufficient to cause obstructed states.

To sketch the runtime behavior of analyzing satisfiability or obstructability, different example nets with an increasing number of tasks, users, and SoD constraints are generated. Figures 3.53 and 3.54 give rough impressions of the smaller instances encoded in the net SecANet representation. A graphical display of larger instances quickly exceeds paper size. In a suitable zoomable digital frame (or on larger paper), a more extensive SecANet is still graphically more intuitive than a purely textual description, since it facilitates understanding of the interdependencies that lead to obstructions.

The experiments were conducted on a MacBook Pro machine, with 8 GB RAM and an Intel Core i7 3 GHz CPU. In order to analyze the WSP instances with a

**Figure 3.53** Impression of generated SecANet with 6 tasks, 60 users, and 1 SoD constraint. The policy-related elements are arranged horizontally. Below them, the WF tasks flow vertically

p50 p52 p51

t6 t7 t8 t9

 <sup>1</sup>

p55

 <sup>1</sup> <sup>1</sup> 

p57 p16 p15

p49 p48

1 <sup>1</sup> <sup>1</sup>

t4 t5

p58

u52t3 u75t3 u63t3 u86t3 u95t3 u60t3 u85t3 u37t3 u3t3 u22t3 u45t3 u59t3 u22t8 u45t8 u52t8 u40t8 u74t8 u72t8 u83t8 u90t8 u37t8 u59t8 u36t8 u85t7 u60t7 u2t7 u37t7 u14t7 u24t4 u45t4 u57t4 u34t4 u40t4 u4t4 u62t4 u97t4 u92t4 u48t4 u83t9 u63t9 u75t9 u52t9 u85t9 u24t9 u48t9 u92t5 u72t5 u97t5 u98t5 u47t5 u13t5 u25t5 u74t6 u97t6 u85t6 u60t6 u48t6 u13t6 u59t6 u47t6 u49t10 u38t10 u73t10 u7t10 u16t10 u72t10 u23t10 u46t10 u89t10 u22t10 u100t10 u68t2 u22t2 u74t2 u75t2 u36t2 u48t2 u47t2 u90t2 u39t2 u47t1 u100t1 u90t1 u36t1 u59t1 u3t1 u2t1 u60t1 u19t1 u86t1 u75t1 u52t1 u51t1

<sup>1</sup>

 <sup>1</sup>

<sup>1</sup> 11

u41t3 u31t3 u91t3 u16t3 u80t3 u27t3 u8t3 u39t8 u49t8 u91t8 u9t8 u27t7 u16t7 u39t7 u1t7 u42t7 u77t7 u54t7 u8t4 u65t4 u88t4 u31t4 u77t4 u41t4 u76t4 u99t4 u38t4 u27t4 u15t4 u65t9 u99t9 u15t9 u39t5 u64t5 u99t5 u54t5 u8t6 u31t6 u88t6 u99t6 u53t6 u49t6 u16t6 u27t6 u91t6 u15t10 u82t10 u31t10 u43t10 u21t10 u77t10 u42t10 u53t2 u76t2 u77t2 u54t2 u91t2 u38t2 u26t1 u54t1 u87t1 u30t1 u76t1 u80t1

u79t3 u33t3 u7t3 u18t8 u29t7 u18t7 u71t7 u7t7 u94t9 u44t9 u33t9 u56t5 u79t6 u94t6 u29t6 u9t10 u70t10 u69t10 u87t10 u76t10 u10t2 u79t2 u44t2 u94t2 u71t2 u82t2 u7t1 u44t1 u67t1 u21t1 u79t1 t1 t2 u82t9 u21t6 t3

 

 

<sup>1</sup>

 <sup>11</sup> <sup>1</sup> 

<sup>1</sup>

 

<sup>1</sup>

u43t3 u89t3 u72t3 u61t3 u70t3 u17t3 u46t3 u6t3 u4t8 u69t8 u32t8 u66t8 u89t8 u50t8 u93t8 u29t8 u28t7 u61t7 u46t7 u46t4 u35t4 u12t4 u61t4 u81t4 u96t9 u81t9 u29t9 u100t9 u43t9 u20t9 u78t9 u4t9 u81t5 u19t5 u95t5 u84t5 u96t5 u73t5 u5t5 u20t5 u66t5 u11t5 u58t5 u96t6 u61t6 u55t6 u35t6 u69t6 u57t6 u28t6 u4t6 u36t10 u68t10 u92t10 u28t10 u40t10 u55t2 u32t2 u50t2 u73t2 u84t2 u12t1 u23t1 u35t1 u11t1 u20t1 u32t1 u95t1 u81t1 u17t1

 <sup>1</sup> <sup>1</sup> <sup>1</sup>

<sup>1</sup>

 

 <sup>1</sup> <sup>1</sup> 

<sup>1</sup>

p5 p8 p4 p9 p2 p6 p3 p0 p1 p7

<sup>1</sup> <sup>1</sup>

<sup>1</sup> <sup>1</sup>

 <sup>1</sup> 

<sup>1</sup>

<sup>1</sup>

<sup>1</sup> <sup>1</sup>

<sup>11</sup>

 

<sup>1</sup>

 

<sup>1</sup> <sup>1</sup>

u70t1

p30 p32 p31 p34 p33 p36 p35 p38 p37 p39 p41 p40 p43 p42 p45 p44 p47 p46

<sup>1</sup>

<sup>1</sup> <sup>1</sup> <sup>1</sup> <sup>1</sup> <sup>1</sup> <sup>1</sup> <sup>1</sup> 

11 111

 <sup>1</sup> <sup>1</sup>

 

<sup>1</sup> <sup>1</sup>

<sup>1</sup>

<sup>1</sup> <sup>1</sup>

<sup>1</sup>

<sup>1</sup>

<sup>1</sup>

<sup>1</sup>

11

<sup>1</sup>

p18 p17 p19 p21 p20 p23 p22 p25 p24 p27 p26 p29 p28

 

 <sup>1</sup>11 

 <sup>11</sup>

<sup>1</sup>

<sup>11</sup>

 111 <sup>1</sup> <sup>1</sup>

 <sup>1</sup>

 <sup>1</sup>

<sup>11</sup>

11

p13

<sup>1</sup> <sup>1</sup> <sup>1</sup> <sup>11</sup>

<sup>1</sup> <sup>1</sup> <sup>1</sup> 

<sup>1</sup> <sup>1</sup> <sup>1</sup>

<sup>1</sup> <sup>1</sup> <sup>1</sup>

11

 <sup>1</sup> <sup>1</sup>

 

<sup>1</sup> <sup>1</sup> <sup>1</sup> <sup>1</sup> <sup>1</sup>

11 <sup>1</sup> <sup>1</sup> 

<sup>1</sup> <sup>1</sup>

<sup>1</sup> <sup>1</sup>

 

<sup>1</sup>

<sup>1</sup>

<sup>1</sup>

<sup>1</sup>

 <sup>1</sup> 

<sup>1</sup><sup>1</sup>

p54 p53

p56

t10

end

p10

u67t3

p12

<sup>1</sup>

<sup>1</sup> <sup>1</sup>

<sup>1</sup>

p11

 

p14

<sup>1</sup> <sup>1</sup> <sup>1</sup>

 <sup>1</sup> 

<sup>1</sup>

<sup>1</sup> <sup>1</sup> <sup>1</sup>

11

<sup>1</sup>

 

<sup>1</sup> <sup>1</sup>

<sup>11</sup> <sup>1</sup>

<sup>1</sup>

 <sup>1</sup><sup>1</sup> <sup>1</sup> <sup>1</sup>

<sup>1</sup>

<sup>1</sup>

 

<sup>1</sup>

<sup>1</sup>

 

11

11

common satisfiability analysis technique, they were encoded using pseudo-Boolean (PB) constraints based on Wang et al. [207] and then solved by the PB solver SAT4J [29]. In a SecANet, satisfiability can be examined by checking whether all WF tasks are not dead (cf. Section 3.2.6.1 on SecANet soundness). For this, the Low Level Petri Net Analyzer (LoLa) was used. That is a well-established, state-ofthe-art Petri net analysis tool, which constantly participates in the Petri net Model Checking Contest (MCC)<sup>18</sup> and demonstrates its competitiveness with other Petri net verification tools. In order to illustrate the time needed to analyze obstructability, the "option to complete" was considered in the test as well. Table 3.1 shows the results of checking different instances for satisfiability and obstructability19. The cells with an indicate that the PB formula or the respective soundness condition could be satisfied. Cells with an ✗highlight unsatisfiable or obstructable instances. In their solutions, both tools offer witness assignments (SAT4J) or witness firing sequences (LoLa) that encode satisfying user-task assignments or cause obstructions. Moreover, since LoLa kills the computation when the computation of the "option to complete" exceeds about 20 minutes, the results for some instances are unknown (the respective results are indicated by a hyphen). It can be seen that the SecANet encoding of the first and fifth WSP instances are sound as well. In terms of computation time, Table 3.1 suggests that the Petri-net-based satisfiability analysis outperforms the analysis of the SAT4J solver by a factor of at least 10. In this regard it should be noted that the SecANet allows examination of the "no dead tasks" property by checking only whether the last task in the execution is not dead. Based on the sequential task order and the considerations regarding the "no dead WF tasks" condition of SecANet soundness, a fireable last WF task renders the entire workflow satisfiable. For the obstructability analysis, the overall rapidly growing time consumption indicates exponential (hence non-polynomial) run-time behavior, which is typical for questions concerning reachability. Checking the "option to complete" condition in a SecANet means a significantly higher level of effort is needed, since from each reachable state it has to be checked whether some marking *m* that contains the output place, that is, *m* ≥ *po*, is reachable.

In conclusion, the tests suggest that the SecANet approach is useful for analyzing satisfiability and that it performs better than the SAT4J alternative. Since there are more elaborate specialized tools for analyzing satisfiability, further approaches could be considered here as well. Moreover, the decreasing runtime for checking the

<sup>18</sup> For further information and tools, see mcc.lip6.fr at the computer-science lab at Sorbonne University, Paris.

<sup>19</sup> The generated process models can be consulted at https://doi.org/10.6094/UNIFR/228177. The archive file generated\_secanets.zip includes a manual on how to reproduce the results.


**Table 3.1** The runtime (in seconds) for analysis of example WSP instances is displayed after the result (i.e., or ✗). Satisfiability was computed with the SAT4J solver and LoLa, which checked the "no dead transitions" (NDT) condition. For obstructability, LoLa checked the "option to complete" (O2C)

option to complete for the 10/12/22 instance suggests a more detailed investigation of how a higher number of constraints tends to lower the computational runtime. However, the foremost intention of running the displayed experiment was to show the applicability of Petri net analysis tools to the SecANet approach. To the best knowledge of the author, there is no other approach that solely uses Petri nets to solve satisfiability or obstructability.

#### **3.2.8 Discussion**

The SecANet approach provides a holistic basis not only for solving questions concerning satisfiability and obstructability but also for resolving obstructions, which will be examined in subsequent chapters. This chapter has introduced the SecANet encoding, which allows flattening of a security-aware process specification containing the workflow, its corresponding user-task assignments, and its authorization constraints into one Petri net such that obstructions can be captured and analyzed. Therefore, the requirements concerning the obstructability analysis set up in Chapter 2 have been addressed to a large extent. The SecANet encoding integrates common constraints (ROA-4) and a comprehensive workflow structure (ROA-2) and allows for encoding and capture of the state of obstruction (ROA-7). Thus it is possible to do ordered assignments of users, as well as pre-assignments (ROA-1). The SecANet encoding is also able to map costs to each of its elements (ROA-6). Execution sequences of the SecANet can be used to generate satisfiable or obstructed partial plans (ROA-5). Thereby, the modeling and encoding have been done in such a way that rather efficient techniques—for example, to check the soundness of a net or an extended net—are applicable (ROA-3). Here in particular, the method used in modeling the constraints, the effort to use efficient techniques, and the question of how additional constraints could be taken into account leave room for discussion.

#### **3.2.8.1 Method of Modeling**

In general, it can be observed that the modeling of the different elements of the policy integrated onto the control flow manifests itself as "permissive" or "restrictive" modeling. Whereas the modeling of authorization explicitly states what is allowed (permissive), the modeling of constraints implicitly determines what is not allowed (restrictive). In the context of language, analogously to permissive or restrictive modeling, one can also speak of language-extending and language-restricting modeling. For example, the modeling of authorizations adds behavior by adding new letters, while the modeling of constraints restricts existing behavior. Thus the question of whether an added net construct is permissive or restrictive can also be identified by observing its impact on the language.

This distinction between permissive and restrictive modeling also allows for explanation of the differences in the traceability of the policy elements. Whereas the user-task assignment would directly provide reconstruction or retracing of the authorization policy by the user-task transitions, this is possible to only a limited extent for constraints. The proposed method of modeling assumes a set of users and a corresponding user-task assignment such that a constraint can be applied only to user-task assignments that are affected by that particular constraint. A constraint is encoded and retraceable only if there are user-task assignments to which the constraint applies. If there are no user-task assignments affected by a constraint, the SecANet approach does not allow for direct representation of such a constraint in the model. Still, the constraint is implicitly given and does not cause unwanted behavior. This situation is also known as static SoD or static BoD [93]. Hence the visibility and the traceability of constraints in the SecANet model depend on the specific user-task assignments. Analogously, the distinction between "permissive" and "restrictive" applies to the existence or absence of the free-choice property. If a choice between transitions is indeed free, then the choice is explicit, and it is permitted to choose between the options provided. When a choice between transitions is not free, there are further conditions that may restrict the choices. The options can then differ depending on whether these further conditions are fulfilled or not.

#### **3.2.8.2 Time, Space, and Output Memory Requirements**

Regarding the computational complexity, in particular, the acyclic SecANet encoding is of interest. The input of the cyclic encoding, in turn, is the output SecANet obtained by the acyclic approach and a set of re-enactment transitions that indicate cycles (cf. Algorithm 3.1). In enhancing the acyclic SecANet with looprelated functionality, the cyclic approach benefits from the net structure already computed by the acyclic encoding. Here, especially the more complex computational compartments of the acyclic approach concerning constraint-related elements will be essential. Moreover, the consideration of acyclic policy-aware workflow nets will allow comparability since related approaches (e.g., regarding the WSP) are typically based on similar input parameters.

For the acyclic SecANet approach that runs on an instance of a policy-aware workflow net -*N*, *U*, *T A*,*C* (cf. Definitions 3.29, 3.30, 3.31, and 3.32), the upper bound complexity will be measured in terms of *n* = |*U*|, *k* = |*T* | (i.e., the tasks encoded by transitions in the workflow net *N*), and *m* = |*C*|. The set of user-task assignments *T A* and its corresponding set of assignment list *T A* corresponds to *k* lists each of size at most *n* (which is, for example, comparable to the WSP instances considered by Cohen et al. [50]).

**Time Complexity:** Based on the assumption that each task has at least a single user assigned, that is, |*T A*|≥|*T* |, a marked place *Pt*−, an unmarked place *Pt*+, and a flow relation -*Pt*+, *t* are created for each task—which is considered as three computational steps. Analogously, based on each entry in the task-assignment list *T A*(*t*), a user-task transition is created together with two arcs that connect *Pt*<sup>−</sup> and *Pt*<sup>+</sup> as incoming and outcoming places, respectively, which results in three computing steps for each user-task permission. That way, the complexity to encode the authorization policy is 3 ∗ |*T* |+|*T A*| . All possible pairwise combinations of tasks determine the maximal number of constraints, that is, <sup>|</sup>*C*| = |*<sup>T</sup>* |−<sup>1</sup> *<sup>i</sup>*=<sup>1</sup> *<sup>i</sup>* <sup>=</sup> <sup>1</sup> <sup>2</sup> (−1 + |*T* |) ∗ |*T* |. The variable *s* ∈ [0; 1] determines the percentage share of SoD constraints of the total number of constraints, such that |*CSoD*| = *s* ∗ |*C*|. The proportion of BoD constraints *b* thus results from *b* = 1 − *s*, accordingly |*CBoD*| = (1 − *s*) ∗ |*C*|. Finding a match between users in the user lists for the two tasks affected by a constraint creates a constraint place and corresponding arcs. In terms of SoD constraints, this means creating the marked SoD place *PSoD* and the arcs for its two outgoing user-task transitions, thus three steps. It is assumed that the same number of users is assigned to each tasks such that all lists have the same length <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> . That way, multiplying the number of steps required for comparing each user of each task list with each user of the other task list by the maximal number of constraints |*C*| also maximizes complexity for the overall search for matches. For a BoD constraint, a marked constraint place *PBoD*, a single arc connecting the BoD place with the user-task transition from the user from the list of the one task, and | |*T A*| <sup>|</sup>*<sup>T</sup>* <sup>|</sup> | −1 arcs that connect the BoD place with the user-task transitions from all the other users from the list of the other task are created—so 1+1<sup>+</sup> <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> <sup>−</sup><sup>1</sup> <sup>=</sup> <sup>1</sup><sup>+</sup> <sup>|</sup>*T A*<sup>|</sup> |*T* | steps. If there exist matches for all users in the lists, this means that <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> = |*U*|, such that the number of steps needed to find each pair is |*T A*| |*T* | *<sup>i</sup>*=<sup>1</sup> *<sup>i</sup>* <sup>=</sup> <sup>1</sup> <sup>2</sup> <sup>∗</sup> <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> ∗ <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> <sup>+</sup><sup>1</sup> . In case no match is found, the comparison of each entry of one list with each entry of the other list requires <sup>|</sup>*T A*<sup>|</sup> |*T* | <sup>2</sup> steps. However, because of *<sup>n</sup>* = |*U*|, finding no matches would imply different users assigned to each task (i.e., only <sup>|</sup>*U*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> <sup>=</sup> <sup>|</sup>*T A*<sup>|</sup> |*T* | <sup>2</sup> users for each task). Then, the comparison of each entry of one list with each entry of the other list only demands <sup>|</sup>*T A*<sup>|</sup> |*T* | <sup>2</sup> )<sup>2</sup> steps. Thus, as the input size increases, the search complexity to find no pairs is less than the complexity required to find matches only. The maximal number of steps for the flattening of all BoD constraints, therefore, results in <sup>1</sup> <sup>2</sup> <sup>∗</sup> <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> ∗ <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> <sup>+</sup><sup>1</sup> <sup>+</sup> <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> ∗ <sup>1</sup> <sup>+</sup> <sup>|</sup>*T A*<sup>|</sup> |*T* | <sup>=</sup> <sup>3</sup> 2 ∗ <sup>|</sup>*T A*<sup>|</sup> |*T* | <sup>2</sup> <sup>+</sup> <sup>3</sup> <sup>2</sup> <sup>∗</sup> <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> , and 1 <sup>2</sup> <sup>∗</sup> <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> ∗ <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> <sup>+</sup> <sup>1</sup> <sup>+</sup> <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> <sup>∗</sup> <sup>3</sup> <sup>=</sup> <sup>1</sup> 2 ∗ <sup>|</sup>*T A*<sup>|</sup> |*T* | <sup>2</sup> <sup>+</sup> <sup>7</sup> <sup>2</sup> <sup>∗</sup> <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> for SoD constraints, respectively. The runtime complexity of the SecANet encoding for the overall policy (i.e., the authorization policy and the constraints) results in:

$$\begin{aligned} &(1-s)\*|C| \ast \left(\frac{3}{2} \ast \left(\frac{|TA|}{|T|}\right)^2 + \frac{3}{2} \ast \frac{|TA|}{|T|}\right) \\ &+ s\*|C| \ast \left(\frac{1}{2} \ast \left(\frac{|TA|}{|T|}\right)^2 + \frac{7}{2} \ast \frac{|TA|}{|T|}\right) + 3 \ast \left(|T| + |TA|\right) \end{aligned}$$

Although this formula allows considering different <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> -ratios, the worst-case assumes that the maximal number of steps is obtained by <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> = |*U*|, which results in:

$$|(1-s)\*|C| \* \left(\frac{3}{2}\*|U|^2 + \frac{3}{2}\*|U|\right) + s\*|C| \* \left(\frac{1}{2}\*|U|^2 + \frac{7}{2}\*|U|\right) + 3\*\left(|T| + |T| \*|U|\right)$$

$$\Leftrightarrow (1-s) \ast m \ast \left(\frac{3}{2} \ast n^2 + \frac{3}{2} \ast n\right) + s \ast m \ast \left(\frac{1}{2} \ast n^2 + \frac{7}{2} \ast n\right) + 3 \ast \left(k + k \ast n\right)$$

That way, |*U*| determines both the number of users and the number of users assigned to each task. Moreover, assuming <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> = |*U*<sup>|</sup> takes care of the case that <sup>|</sup>*T A*<sup>|</sup> must not be smaller than |*T* |. Because encoding BoD constraints requires more steps, the complexity is maximal if *s* = 0 (or |*C*|=|*CBoD*|), which results in *<sup>m</sup>* <sup>∗</sup> ( <sup>3</sup> <sup>2</sup> <sup>∗</sup> *<sup>n</sup>*<sup>2</sup> <sup>+</sup> <sup>3</sup> <sup>2</sup> ∗ *n*)+3 ∗ *k* ∗ (1+*n*). Hence, the acyclic SecANet encoding is in the class of efficient algorithms that run in quadratic time *<sup>O</sup>*(*<sup>m</sup>* <sup>∗</sup>*n*2). Thus, it belongs to the class of FPT-algorithms *<sup>O</sup>*( *<sup>f</sup>* (*k*) <sup>∗</sup> *<sup>n</sup>c*) (cf. Chapter 2). Based on the worst-case assumption that the maximal number of constraints is *<sup>m</sup>* <sup>=</sup> *<sup>f</sup>* (*k*) <sup>=</sup> ( <sup>1</sup> <sup>2</sup> ∗(*k* −1)∗*k*), this results in ( <sup>1</sup> <sup>2</sup> <sup>∗</sup> (*<sup>k</sup>* <sup>−</sup> <sup>1</sup>) <sup>∗</sup> *<sup>k</sup>*) <sup>∗</sup> ( <sup>3</sup> <sup>2</sup> <sup>∗</sup> *<sup>n</sup>*<sup>2</sup> <sup>+</sup> <sup>3</sup> <sup>2</sup> ∗ *n*) + 3 ∗ *k* ∗ (1 + *n*) which is in *<sup>O</sup>*(*n*<sup>2</sup> <sup>∗</sup> *<sup>k</sup>* <sup>∗</sup> (*<sup>k</sup>* <sup>−</sup> <sup>1</sup>) <sup>+</sup> (*k*<sup>2</sup> <sup>∗</sup> *<sup>n</sup>*)). From practice, it can be assumed that the number of tasks usually is an order of magnitude smaller than the number of users [50]. Even the case that *<sup>n</sup>* <sup>=</sup> *<sup>k</sup>* results in <sup>3</sup> <sup>4</sup> <sup>∗</sup>*n*<sup>4</sup> <sup>+</sup> <sup>9</sup> <sup>4</sup> <sup>∗</sup>*n*<sup>2</sup> <sup>+</sup>3∗*<sup>n</sup>* and still is in quartic complexity in the number of users (i.e., *O*(*n*4)).

**Space Complexity:** For all steps, a constant number of iteration variables can be assumed. The authorization-related elements can directly be created by iterating over the task-assignment lists in *T A*, which gives the list of users assigned to each task. Moreover, based on each constraint in *C* involving a pair of tasks, the corresponding lists of users can be obtained again based on the given input. Hence, besides a fixed number of iteration variables, no additional input-dependent space is required to iterate over the lists for two tasks. All generated elements are directly written to the output (which is not read again). Hence, the acyclic encoding is in constant space complexity *O*(1).

**Input/Output Ratio:** If one compares, for example, the XES log format mentioned in Chapter 2 with the older MXML log format, the MXML format requires about four times the memory for identical log content. Similarly, based on the memory required for the policy-related part in a policy-aware workflow net, which constitutes the inputs of WSP problem instances, a comparison is possible to the output memory used by the SecANet. However, such a comparison must take into account that the SecANet brings a significant added value compared to the plain input contained in a policy-aware workflow net. First, in a SecANet, there is a place pair |*P*−+| = 2 for each task, thus |*P*˙ *T A*| = 2 ∗ |*T A*|. Moreover, the number of usertask assignments |*T A*| in the policy determines the user-task transitions |*T*˙ *T A*| in a SecANet. Additionally, for each user-task transition, two arcs connect it to the places indicating unassignment and assignment, and there is an arc that connects the corresponding task, which sums to *F*˙ *T A* = |*T A*| ∗ 2 + |*T* |. Hence, all Petri net elements related to |*T A*| result in:

$$|\dot{P}\_{TA}| + |\dot{T}\_{TA}| + |\dot{F}\_{TA}| = 2 \ast |TA| + |TA| + |TA| \ast 2 + |T| = \mathfrak{F} \ast |TA| + |T|.$$

Similarly to the maximal runtime complexity, the maximal number of elements is assumed if all users are assigned to all tasks (|*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> = |*U*|). Then, for large *<sup>n</sup>* = |*U*|, the input/output ratio for the authorization-related input |*T A*|+|*T* |=|*U*|∗|*T* |+|*T* | converges to the factor:

$$\lim\_{n \to \infty} \frac{k + \mathcal{S} \* n \* k}{k + n \* k} = \mathcal{S}$$

Analogous to the runtime complexity, the worst-case assumption for the output is that all users assigned to the two tasks involved in a constraint are also affected by the constraint. This results in the number of constraint places |*P*˙ *<sup>C</sup>*|=|*C*| ∗ <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> for both cases *P*˙ *<sup>C</sup>* = *P*˙ *SoD* and *P*˙ *<sup>C</sup>* = *P*˙ *BoD*. The difference here lies in the number of arcs, namely |*F*˙*SoD*| = 2 ∗ |*P*˙ *SoD*<sup>|</sup> and <sup>|</sup>*F*˙*BoD*| = <sup>|</sup>*T A*<sup>|</sup> <sup>|</sup>*<sup>T</sup>* <sup>|</sup> ∗ |*P*˙ *BoD*|, respectively. Hence, the worst-case output memory required for all policy-related elements of the SecANet results in:

$$\left( \left( \frac{|TA|}{|T|} + 1 \right) \* \left( |C\_{BoD}| \* \frac{|TA|}{|T|} \right) \right) + \left( \mathfrak{Z} \* |C\_{SoD}| \* \frac{|TA|}{|T|} \right) + \left( \mathfrak{Z} \* |TA| + |T| \right)$$

**Figure 3.55** DMV free-choice SecANet with initial marking

Here, the worst-case assumption again is that every user is assigned to every task:

$$(1-s)\*|C|\*\left(|U|^2+|U|\right)+\mathfrak{Z}\*s\*|C|\*|U|+\mathfrak{Z}\*|U|\*|T|+|T|$$

$$\Leftrightarrow (1-s)\*m\*(n^2+n)+s\*m\*\mathfrak{Z}\*n+\mathfrak{Z}\*k\*n+k$$

Hence, while the output of authorization-related elements is approximately five times the input size only, the encoding of constraints significantly increases the input size *<sup>m</sup>* = |*C*<sup>|</sup> by factor *<sup>m</sup>*∗(*n*2+*n*) *<sup>m</sup>* <sup>=</sup> *<sup>n</sup>*<sup>2</sup> <sup>+</sup> *<sup>n</sup>* (only BoD) and *<sup>m</sup>*∗3∗*<sup>n</sup> <sup>m</sup>* <sup>=</sup> <sup>3</sup> <sup>∗</sup> *<sup>n</sup>* (only SoD), respectively. Still, in the face of both the pessimistic worst-case assumptions and the added value of the SecANet output—in particular, its graph-based policy visualization, its execution semantics, and its applicability to Petri net-related analysis—the increased output memory requirements can be regarded as moderate.

#### **3.2.8.3 More Efficient Analysis**

Although the SecANet has important properties for fostering an efficient computation—for example, the overall net still represents a safe P/T net—the exponential growth of the runtime in obstructability analysis indicated by the example in Table 3.1 underlines the necessity to strive for more efficient techniques. Here, for a more efficient analysis of the obstructability of a SecANet, the repeatedly discussed endeavor of achieving the free-choice (FC) property could be pursued further. The rationale is that the satisfiability and obstructability of a live, safe, and reversible free-choice SecANet may be efficiently solvable as well. The previously explained transformations for arbitrary Petri nets into free-choice nets [124, 187, 188] can be used for that purpose. However, making a net "free choice" would be accompanied by a further increase in the structural complexity of the net. More precisely, assuming a SecANet that contains a free-choice WF-net, the free-choice transformation has to be done for all other net constructs, that is, the user-task assignments, constraints, and re-enactment-related constructions would have to be transformed accordingly.

Because of the structural properties of the SecANet modeling and the assumed block structure, the non-free-choice (NFC) elements of a net that have been considered here are indeed not so "arbitrary." They already show such a structural limitation that they can be transformed into a free-choice net by only a few modifications. Figure 3.55 depicts a method by which the example DMV can be transformed into a free-choice net. For each user-task assignment, a single transition and a single place are added. Moreover, for each user-task assignment affected by the SoD constraint, a place and transition are inserted as well, hence each choice must be made explicitly. For example, not only does the SoD place restrict the execution of user tasks, but it has to be explicitly decided whether the SoD place is to be put into action as well as for which user-task assignment it should take effect. The free-choice-related elements, therefore, allow a more detailed breaking down of the decisions taken during the process. Currently, the transitions are silent and do not add behavior to the net. However, one could also consider labeling them—for example, in order to explicitly encode the choices made in the execution sequences as well.

Hence although the increase in the structural complexity of the example DMV which is caused by the transformation into a free-choice net remains moderate, the transformation extends the state space and creates intermediate transitions. Both the new states and the new transitions demand interpretation. In this regard, the marking in Figure 3.56 relates to the obstruction marking of the DMV SecANet. Figures 3.57 and 3.58 display new variants of terminal markings that seem to obstruct as well.

On the one hand, the results of a free-choice SecANet can be interpreted with regard to the initial SecANet. Here, the markings in Figures 3.56 and 3.57 could be interpreted as "false-positive" obstruction markings, since they have no obvious relation to any marking of the underlying SecANet. In fact, in Figure 3.58 it looks as though the SoD constraint is fired "the wrong way," and that it is even more restrictive. Such false-positive obstructions could be filtered out by backward firing the leftover tokens in the FC places (directly above the user-task transitions) of

**Figure 3.56** DMV free-choice SecANet with obstruction marking (true positive)

**Figure 3.57** DMV free-choice SecANet with new variant of a potential obstruction marking (false positive)

the terminal marking.Thus the firing is first reversed such, so that the corresponding user-task assignment or constraint place is marked again. Then if some firing sequences allow escaping the deadlock, the marking is not a "real" obstruction. For example, the deadlock in Figure 3.58 could be resolved by backward firing the SoD-related token in the free-choice place and then firing the right-hand SoD transition of the free-choice-related nodes. Thus *tu*1*t*<sup>2</sup> would be enabled in such a way that the deadlock would be resolvable. If SoD places do not affect a workflow execution, it would not matter if the left-hand or right-hand FC-SoD-transition is fired. Based on this backward-firing method, all example deadlock markings can be avoided, except for the marking in Figure 3.56, which is the one that represents the SecANet obstruction.

On the other hand, these new markings could also be re-interpreted with regard to the initial SecANet. For example, the free-choice-related Petri net elements could be interpreted as a sort of assignment reservation, anticipation, pre-assignment, or pre-decision, and as such could encode further states. Moreover, these elements could be related to costs. In an SoD constraint, for example, costs could be assigned to the FC elements to determine which of the user-task assignment should preferably be enabled.

Hence a free-choice SecANet would require some filtering of the results or at least some rules of interpretation, but it seems as though the effort needed for such a transformation would be manageable. Moreover, there seem to be only false-positive

**Figure 3.58** DMV free-choice SecANet with further variant of a potential obstruction marking (false positive)

obstructions and no false-negative ones. Thus in case of doubt, the result of an analysis of a free-choice SecANet may be too restrictive, but at least it would not overlook obstructions. Regardless of the chosen interpretation, by such a "free-choice preprocessing" the analysis of SecANet soundness may be done more efficiently. Therefore, it would be interesting to compare the potential increase in efficiency with the increase in net elements (i.e., the structural complexity) caused by the free-choice transformation and how the computation of the initial NFC SecANet compares to it. Here, the free-choice transformation of the re-enactment constructions for a cyclic SecANet or a SecA-WF-Net seems to be structurally much more complex.

Besides the effort to make a SecANet free choice, SecANet-specific analysis could be refined and certainly optimized. Based on the well-defined SecANet construction rules elaborated in this chapter, the SecANet offers the possibility for further structural analysis, property-preserving reductions, or simplification of the nets. For example, in order to reduce search space, only places or transitions which are of interest in regard to the occurrence of an obstruction could be considered. Then, for example, the question of whether every transition related to re-enactment is live could be ignored. Furthermore, the identification of typical obstruction patterns could facilitate the search for obstructions.

#### **3.2.8.4 Common and Further Constraints**

The applicability of the SecANet approach has been illustrated for common constraints, namely user-task assignments and SoD/BoD constraints. Thus far, in order to cause obstructions, SoD constraints have been of greatest interest. The neglect of BoD constraints is not unusual in WSP research. There, BoD constraints are eliminated during preprocessing, before solving a WSP instance [48]. On the one hand, the relation of BoD constraints to obstructability depends on how consistently a BoD is actually defined and whether it is considered in the authorization policy as well. Since a BoD constraint binds two tasks to the same user, if a certain user is not authorized for both tasks and executes one of them, the other task is not trivially executable. For example, Figure 3.26b displays an encoding of a BoD constraint, which may indeed cause such an obstruction, namely, if *tu*2*t*<sup>1</sup> is executed. Because of the missing assignment of user *u*<sup>2</sup> to *t*2, this part of the BoD constraint cannot be trivially fulfilled. Here, one could indeed consider eliminating the assignment encoded by *tu*2*t*<sup>1</sup> . On the other hand, even if such contradictions between BoD constraints and the authorizations are avoided, the BoD constraints can still foster obstructions, since they basically restrict possible user-task assignments. This can in turn restrict the user-task assignments that satisfy the SoD constraints. As an example, Figure 3.59 shows a variation of the DMV SecANet that can obstruct because of the interplay between the SoD and BoD constraints. In that case, the workflow offers the additional possibility that the person who will later control the market value is first asked to compute an independent market value without bias. This could be done on a random basis—or, for example, if the calculated market value exceeds a certain threshold. Figure 3.60 shows the corresponding obstruction marking, which occurs after *tu*1*t*<sup>1</sup> , *t*1, *tu*1*t*<sup>3</sup> , and *t*<sup>3</sup> are fired. Here, on the one hand a BoD constraint obstructs the execution of *tu*3*t*<sup>4</sup> , and on the other hand an SoD constraint obstructs *tu*1*t*<sup>4</sup> .

In general, the constraints considered so far in the SecANet modeling represent entailment constraints that are sufficient to obstruct the process. The basic assumption for SecANet modeling is that the scope of the constraint entails two tasks. However, if one or both sides of a binary constraint encompass sets of tasks, this can be encoded with several choice places where each place models a separate conflict between two user-task assignments. Thus the entailment constraints that encompass sets of tasks can be broken down into several conflicting user-task pairs. The flattening does not restrict these entailment constraints in terms of the cardinalities of the involved sets of tasks. However, the focus is on the basic constraint on two singletons, which allows for straightforward application and explanation of the approach. However, beyond SoD or BoD constraints, there are further constraints (cf. Section 2.1.2.4), such as counting constraints, that could contribute to the occur-

recompute market value independently

**Figure 3.59** Variation of the DMV SecANet with SoD and BoD constraints causing an obstruction

recompute market value independently

**Figure 3.60** Obstruction marking in the variation of the DMV SecANet

rence of obstructions but are not yet covered by the approach. Moreover, role-based access control models could be integrated as well.

In general, the policy encoded in the SecANet can also be seen as a conflict between the allocation of resources, where the resource is the token that allows assignment. The notion of resource allocation becomes even more apparent in the modeling of the availability of resources or users. In this regard, one could think of how a task-specific subnet could be modeled that encodes resilience and and then incorporates it into the given net. In order to address such extensibility, in the final section of this chapter an extension of the SecANet approach will be presented, namely SecANet+. That can be seen as the epilogue of this chapter and suggests a general extensible framework for modeling of security-aware Petri nets that incorporates the policy elements considered so far as well as further constraints or restrictions that may impede the process execution.

#### **3.3 SecANet+: Extension of the SecANet Approach**

SecANet+ generalizes the SecANet approach with a deliberate focus on extensibility and modularity. Still, the preceding description of the SecANet approach is necessary to understand the idea, meaning, and purpose of the SecANet+ approach in context. The SecANet approach integrates all net elements directly into the workflow net. Then the decomposition of the SecANet allows for the determination of the language of its subnets and the composition of its overall language (cf. Section 3.2.4.5). SecANet+ , in contrast, aims to build the individual (sub)nets first and then combine these nets. Therefore, the properties and languages can be directly determined for each net separately and for the combined nets, so that there is no need for an elaborate decomposition and recomposition. Again, the use of Petri nets will be rewarding, since the previously introduced net synchronization operator (subsequently indicated by *sy*Σ) will play a central role. Although the composition of languages will need to consider the prefix language, the nets and languages resulting from the SecANet and SecANet+ are the same for the same input and modeling method. Because of its modular setup, the SecANet+ approach builds the basis for further extensions—for example, for further constraints or to model further behavior that in some way constrains or restricts the workflow execution.

The overall framework of the SecANet+ approach is depicted in Figure 3.61. As with SecANet, the intuition behind SecANet+ is to capture every input in a processoriented way—in particular, by including further inputs that in some way restrict the execution of tasks, such as counting not only the constraints but also user absences. The SecANet+ approach is twofold:

**Figure 3.61** The SecANet+ approach


nets are successively combined into one representation by using the synchronization net operator (indicated by *sy*<sup>Σ</sup> in Figure 3.61). As previously explained, the synchronization operator can synchronize two nets with each other by using the activity or transition labelings that are in both nets (i.e., their "common denominator").

By this modular, twofold approach, the SecANet+ provides higher modularity and flexibility in choosing the constraints that affect process execution in some way as well as in combining them into a single representation. Elements of the encoded policy can be stored and kept available. For example, the policy nets and workflow nets could be created and maintained independently of each other in a kind of construction kit which could be combined (or synchronized) only when required. This could save repeated modeling effort, since, for example, the same policy element can be applied to different workflow constellations or only slight adjustments in transition labeling would be required to re-use a modeled net, for example, because of changes in activity names. Moreover, changes that affect only parts of the policy may be done in a better way, without recomputing the entire encoding. Thus it could be possible to remove unused parts of an already existing policy.

In order to explain the SecANet+ approach, this section will first show how to create the building blocks that represent the different process-specific inputs and then later show how to compose them. Since much of this is similar to the SecANet approach, only the key points will be examined more closely, and they will be explained only by way of example, in order to show the applicability. For this reason, first the creation of the policy-related nets that consider the authorization policy and SoD constraints that are comparable with the SecANet approach are described. Then the combination of the resulting nets is described and exemplified with the DMV SecANet. As a final example of an extension of the approach, user availability will be modeled in a way that encodes resilience.

#### **3.3.1 Create and Combine Policy Nets for Workflows**

Figure 3.62 depicts the application of the SecANet+ approach to the considered security-aware process specification, namely a WF-net, a user-task authorization, and SoD constraints. What the processes, the authorization, and the constraints all have in common is their consideration of the activities in some way. More precisely, the "common denominator" of the inputs considered so far consists of the process tasks or the user-activity assignments, as depicted in Figure 3.62. Here, modeling of the individual inputs is indicated by separate rectangles. Then these individual nets are combined by synchronizing the net on their common transitions (i.e., *input*<sup>1</sup> ∩ *input*<sup>2</sup> ). Note that, in contrast to the decomposition of the SecANet, the terminal markings resulting from the overall composition of the different nets cannot be determined prior to the synchronization. If, for instance, the only final marking which was assumed for a net that models user-task authorization is ∅, this would then exclude other terminal markings that would result from synchronization. Therefore, the final marking is assumed to contain all reachable markings. Accordingly, the final marking determines the prefix language of the net (cf. Definition 3.41).

#### **3.3.1.1 Creating Policy Nets**

The generalized encoding of acyclic nets is described here, and it will be illustrated by the example DMV process in Figure 3.21. As mentioned in the first step of the approach, it must first be known which of the nets are to be combined later. Hence the first step of the approach is to model the policy with Petri nets. Thus the policy modeling presented in Section 3.2.2 can now be adapted to the creation of individual processes, independent of the process model, so each Petri net can be regarded separately (cf. Figure 3.62). In order to avoid confusion with previous definitions

**Figure 3.62** SecANet+ for security-aware process specification, with user-task authorization and SoD

of the SecANet encoding, "tasks" will now be termed "activities.". Therefore, in the SecANet+ approach, the user-task authorization *T A* will be replaced with useractivity authorization *U A*, where the set of activities *A* is used analogously to the set of tasks *T* . In order to have common transitions in the two nets, a user-activity Petri net models the activity for which it describes the given authorizations.

**User-Activity Petri Net:** Since the actual user-activity assignment and the subsequent access to the activity shall be modeled, the activity needs to be involved as well. Equivalently to the SecANet, "−" stands for the "unassigned" state, and "+" stands for the "assigned" state.

**Definition 3.75 (User-Activity Petri Net).** *Let a* ∈ *A be an activity such that there exists a user u* ∈ *U where* (*u*, *a*) *is an element of the user-activity relation UA* ⊆ *U* × *A, that is, user u is mapped to activity a. Hence the set of all users authorized for activity a can be denoted by*

$$U\_a = \{ u | u \in U, \ (u, a) \in U \\ A \} = \{ u\_1^a, u\_2^a, \dots, u\_n^a | n = | U\_a | \}.$$

*Based on this, the language-generating Petri net for activity a*, *NUA a* = -*P*, *T* , *F*, *m*0,[*m*0, *T* , *idT , is defined with*

*Pa*−+ = {*p*<sup>−</sup> *<sup>a</sup>* , *p*<sup>+</sup> *<sup>a</sup>* }*,*

*T* = {*ta*}∪{*tua*|*u* ∈ *Ua*}*,*

*F* = {*p*− *<sup>a</sup>* , *t*,*t*, *p*+ *<sup>a</sup>* |*t* ∈ *T* − {*ta*}} ∪ {*p*+ *<sup>a</sup>* , *ta*}*, and*

*mo* = -1, 0*. The figure below shows the graphical representation of such a net NUA <sup>a</sup> :*

**Figure 3.63** Example of user-activity net *NUA a*1

Figure 3.63 shows an example of the encoding of the user-activity assignment for the activity "compute market value" of the DMV process. Given that user *u*<sup>1</sup> and user *u*<sup>2</sup> are authorized for activity *a*<sup>1</sup> and user *u*<sup>1</sup> is authorized for *a*2, this is formalized with the activity set *A* = {*a*1, *a*2}, the user set *U* = {*u*1, *u*2}, and the user-activity assignment *UA* = {(*u*1, *a*1), (*u*2, *a*1), (*u*1, *a*2)}. Then for *a*<sup>1</sup> the useractivity Petri net *NUA a*<sup>1</sup> = -*P*, *T* , *F*, *m*0 consists of the components

$$\begin{array}{l} P = \{p\_{a\_1}^-, p\_{a\_1}^+\}, \\ T = \{t\_{a\_1}, t\_{u\_1 a\_1}, t\_{u\_2 a\_1}\}, \\ \mathcal{F} = \{\langle p\_a^+, t\_{a\_1}\rangle, \langle p\_a^-, t\_{u\_1 a\_1}\rangle, \langle p\_a^-, t\_{u\_2 a\_1}\rangle, \langle t\_{u\_1 a\_1}, p\_a^+\rangle, \langle t\_{u\_2 a\_1}, p\_a^+\rangle\}, \\ m\_o = \langle 1, 0\rangle. \end{array}$$

The graphical representation of the Petri net *NUA <sup>a</sup>*<sup>1</sup> is depicted in Figure 3.63. The properties of such a net, as well as its language, are directly observable. User-activity Petri nets are safe (i.e., 1-bounded) and free choice. Compared to the language of a user-task subnet in Definition 3.51, the language of a user-activity net is easier to determine, namely *L*(*NUA <sup>a</sup>* ) = Pre {*tu*1*a*, *tu*2*a*,..., *tun <sup>a</sup>*}·{*ta*}. For the example, the set of possible words of the language of the net is *L*(*NUA <sup>a</sup>*<sup>1</sup> ) = Pre {*tu*1*a*<sup>1</sup> *ta*<sup>1</sup> , *tu*2*a*<sup>1</sup> *ta*<sup>1</sup> }.

**Modeling of SoD Constraints:** Analogously to the user-activity assignments, the SoD constraints can be defined as an elementary choice construct, given the type of relation (=) and the involved activities. In order to allow the combination with the given authorizations, as indicated in Figure 3.62, what needs to be considered are the user-activity authorizations which will later build the common denominator that will combine them with the user-activity nets.

**Figure 3.64** Example of a user-specific SoD Petri net *<sup>N</sup>*(*a*1,*a*2,=) *<sup>u</sup>*<sup>1</sup>

**Definition 3.76 (User-Specific SoD Petri Net).** *Let u* ∈ *U be a user, and let a*, *b* ∈ *A be two activities such that there exists an SoD constraint cSoD* ∈ *C of the form* (*a*, *b*, =)*, that is, activities a and b may not be executed by the same user, and the user-activity relations* (*u*, *a*), (*u*, *b*) ∈ *UA. The language-generating user-specific SoD Petri net is defined as N*(*a*,*b*,=) *<sup>u</sup>* <sup>=</sup> -*P*, *T* , *F*, *m*0,[*m*0, *T* ,*idT with*

*<sup>P</sup>* = {*psod uab*}, *T* = {*tua*, *tub*}, *F* = {*psod uab*, *tua*,*psod uab*, *tub*}*, and mo* = -1*. The figure below shows the general graphical representation of such a net N*(*a*,*b*,=) *<sup>u</sup>* : pSoDuab t ua t ub

Figure 3.64 is the graphical representation of the SoD net *<sup>N</sup>*(*a*1,*a*2,=) *<sup>u</sup>*<sup>1</sup> of the DMV example and consists of the components

*<sup>P</sup>* = {*psod <sup>u</sup>*1*a*1*a*<sup>2</sup> }, *T* = {*tu*1*a*<sup>1</sup> , *tu*1*a*<sup>2</sup> }, *F* = {*psod <sup>u</sup>*1*a*1*a*<sup>2</sup> , *tu*1*a*<sup>1</sup> ,*psod <sup>u</sup>*1*a*1*a*<sup>2</sup> , *tu*1*a*<sup>2</sup> }, and *mo* = -1.

It can directly be seen that SoD Petri nets are safe and free choice. The language of such a user-specific SoD net can be denoted by *<sup>L</sup>*(*N*(*a*,*b*,=) *<sup>u</sup>* ) <sup>=</sup> Pre {*tua*, *tub*}. Hence the language of the example net is *<sup>L</sup>*(*N*(*a*1,*a*2,=) *<sup>u</sup>*<sup>1</sup> ) <sup>=</sup> Pre {*tu*1*a*1, *tu*2*a*1}.

#### **3.3.1.2 Combining Policy-Related Nets and the Workflow**

After these components are created, they are combined by using the net synchronization operator (cf. Definition 3.45). For the sake of clarity, it is recommended hat the respective net types be synchronized first with themselves and then with the other net types, analogously to the order of composition in Sections 3.2.4.5 and 3.2.4.4. Moreover, in order to consider the full behavior of the nets, their prefix languages must be determined. Therefore, all reachable markings represent the final markings. Since the final markings are again transformable into normal form and all nets are free, the language of the combined nets can again be determined with the help of the restriction operator—or, if the synchronization alphabet is empty, by the shuffle operator. For the user-activity assignments and the SoD constraints, the combination of the individual nets ultimately results in the same net as in the SecANet approach. An example of this will now be used to demonstrate the applicability of the approach.

Similarly to the composition in Section 3.2.4.4, the synchronization alphabet for the synchronization of the user-activity nets is empty, since each user-activity net is created separately. Figure 3.65 gives the net of the combined example activity nets, namely *NUA <sup>A</sup>* <sup>=</sup> *<sup>N</sup>UA <sup>a</sup>*<sup>1</sup> *sy*<sup>∅</sup> *<sup>N</sup>UA <sup>a</sup>*<sup>2</sup> . Moreover, analogously to Section 3.2.4.4, its language can be directly deduced, specifically *L*(*NUA <sup>A</sup>* ) = Pre *L <sup>N</sup>UA a*1 - *L <sup>N</sup>UA a*2 = Pre {*tu*1*a*<sup>1</sup> *ta*<sup>1</sup> , *tu*2*a*<sup>1</sup> *ta*<sup>1</sup> } - Pre {*tu*1*a*<sup>2</sup> *ta*<sup>2</sup> } . This modular combination allows for direct observation of the properties of the combined net constructs. For example, it can be seen that when the user-activity nets are combined, the resulting nets are safe and free choice. This contrasts with synchronization of user-specific SoD nets, as in Section 3.2.4.4, where the restriction operator needs to be applied to determine their language. Since in the example there is only one user-specific SoD net, the language of all user-specific SoD nets is *<sup>L</sup>*(*NSoD*) <sup>=</sup> Pre {*tu*1*a*1, *tu*2*a*1}. Figure 3.66 shows the graphical net that results from the synchronization of all net elements for the example net. The synchronized activities are highlighted by "*sy*."

**Language Composition:** The separate modeling allows for direct examination of the language of the generated nets. Since it is not known beforehand which terminal markings will ultimately result from the synchronization of the nets, the prefix language has to be assumed for the individual nets here. Otherwise, words that might result from later combinations would be excluded from the beginning. Thus the prefix language of each individual net first includes all possible words. In the

**Figure 3.65** Combination of the two example user-activity Petri nets *NUA A*

**Figure 3.66** Example DMV SecANet *NUA sy SoD* <sup>w</sup>*<sup>f</sup>* after combining all nets

course of the synchronization, every prefix or word that becomes impossible will be "cut out" step by step. The terminal language of the composed net can then be derived by considering the full prefixes only. Here, the last letter of a word indicates that a terminal marking has been reached. Such a full word sequence of a prefix language ends when there are no further letters that could be appended, that is, when no further markings are reachable. If the words that encode the terminal firing sequences of the combined net contain all the letters of the full prefix words of the prefix language of the WF-net, they represent satisfiable words; otherwise, they represent obstructed words.

To illustrate this, the language of the DMV SecANet+ will be determined. The prefix language of the workflow net *N*w*<sup>f</sup>* that encodes the DMV control flow is *L*(*N*w*<sup>f</sup>* ) = Pre ({*ta*<sup>1</sup> *ta*<sup>2</sup> }). The synchronization of the prefix language is advantageous, since the intersection operator may easily consider prefixes and not only full words. For example, because of the prefix notation, the word *ta*<sup>1</sup> is already included as a prefix in *L*w*<sup>f</sup>* = Pre ({*ta*<sup>1</sup> *ta*<sup>2</sup> }). Thus the prefix notation can be used to determine the (terminal) language of the DMV SecANet more elegantly. First, the languages of the two policy-related nets can be combined.

*LUA <sup>A</sup>* -*LSoD* <sup>=</sup> ((*LUA <sup>A</sup>* - (*SoD* <sup>−</sup> *UA <sup>A</sup>* ) <sup>∗</sup>) <sup>∩</sup> ( *LSoD* - (*UA <sup>A</sup>* − *SoD*) ∗)) <sup>=</sup> ((Pre ((*tu*2*a*<sup>1</sup> <sup>∪</sup> *tu*1*a*<sup>1</sup> ) *ta*<sup>1</sup> *tu*1*a*<sup>2</sup> *ta*<sup>2</sup> ) - (*SoD* <sup>−</sup> *UA <sup>A</sup>* ) ∗) <sup>∩</sup> (Pre (*tu*1*a*<sup>1</sup> <sup>∪</sup> *tu*1*a*<sup>2</sup> ) - (*UA <sup>A</sup>* − *SoD*) ∗)) <sup>=</sup> ((Pre ((*tu*2*a*<sup>1</sup> <sup>∪</sup> *tu*1*a*<sup>1</sup> ) *ta*<sup>1</sup> *tu*1*a*<sup>2</sup> *ta*<sup>2</sup> ) - (∅) ∗) <sup>∩</sup> (Pre (*tu*1*a*<sup>1</sup> <sup>∪</sup> *tu*1*a*<sup>2</sup> ) - ({*tu*2*a*<sup>1</sup> , *ta*<sup>1</sup> , *ta*<sup>2</sup> }) ∗)) <sup>=</sup> (Pre (({*tu*2*a*<sup>1</sup> , *tu*1*a*<sup>1</sup> }) *ta*<sup>1</sup> *tu*1*a*<sup>2</sup> *ta*<sup>2</sup> )) <sup>∩</sup> (Pre ({*tu*1*a*<sup>1</sup> , *tu*1*a*<sup>2</sup> }) - ({*tu*2*a*<sup>1</sup> , *ta*<sup>1</sup> , *ta*<sup>2</sup> }) ∗)) <sup>=</sup> ((Pre ({*tu*2*a*<sup>1</sup> *ta*<sup>1</sup> , *tu*1*a*<sup>1</sup> *ta*<sup>1</sup> } *tu*1*a*<sup>2</sup> *ta*<sup>2</sup> )) <sup>∩</sup> (Pre ({*tu*1*a*<sup>1</sup> , *tu*1*a*<sup>2</sup> }) - ({*tu*2*a*<sup>1</sup> , *ta*<sup>1</sup> , *ta*<sup>2</sup> }) ∗)) <sup>=</sup> (Pre (({*tu*2*a*<sup>1</sup> *ta*<sup>1</sup> *tu*1*a*<sup>2</sup> *ta*<sup>2</sup> , *tu*1*a*<sup>1</sup> *ta*<sup>1</sup> *tu*1*a*<sup>2</sup> *ta*<sup>2</sup> })) <sup>∩</sup> (Pre ({*tu*1*a*<sup>1</sup> , *tu*1*a*<sup>2</sup> }) - ({*tu*2*a*<sup>1</sup> , *ta*<sup>1</sup> , *ta*<sup>2</sup> }) ∗)) <sup>=</sup> Pre ({*tu*2*a*<sup>1</sup> *ta*<sup>1</sup> *tu*1*a*<sup>2</sup> *ta*<sup>2</sup> , *tu*1*a*<sup>1</sup> *ta*<sup>1</sup> }).

Analogously, the synchronization of the prefix languages of the policy net and the WF-net is as follows:

$$\begin{split} L(N\_{wf}) \circledast \mathrm{L}(N^{UA\text{ sy }SoD}) &= \ & L(N\_{wf}) \mathrm{syd}\_{\sum\_{wf} \subset \Sigma^{UA\text{ sy }SoD}} L(N^{UA\text{ sy }SoD}) \\ &= & (L(N\_{wf}) \mathrm{syd}\_{\{u\_1, u\_2\}} L(N^{UA\text{ sy }SoD}) \\ &= & ((L\_{wf} \sqcup (\Sigma^{UA\text{ sy }SoD} - \Sigma\_{wf})^{\*}) \\ &\qquad \cap (L^{UA\text{ sy }SoD} \sqcup (\Sigma\_{wf} - \Sigma^{UA\text{ sy }SoD})^{\*})) \\ &= & (\mathrm{Pre} \,(\langle t\_{a\_1}, t\_{a\_2} \rangle \sqcup (\langle t\_{u\_1a\_1}, t\_{u\_2a\_1}, t\_{u\_1a\_2} \rangle)^{\*})) \\ &\qquad \cap (\mathrm{Pre} \,(\langle t\_{a\_{21}a\_1}, t\_{a\_{12}}I\_{t\_{a\_2}}, t\_{u\_{11}a\_{11}}l\_{a\_{11}} \rangle) \sqcup (\langle \theta^{\*} \rangle))) \\ &= & ((\mathrm{Pre} \,(\langle t\_{a\_1}, t\_{a\_2} \rangle) \sqcup (\langle t\_{u\_{11}a\_1}, t\_{u\_{12}a\_1}, t\_{u\_{11}a\_2} \rangle))^{\*})) \\ &\qquad \cap \mathrm{Pre} \,(\langle \langle t\_{u\_{21}a\_1} \sqcup I\_{t\_{u1}a\_2}I\_{t\_{a2}}, t\_{u\_{11}a\_1}l\_{a\_{11}} \rangle \rangle) \\ &= & \mathrm{Pre} \,(\langle (t\_{u\_{21}a\_1} \sqcup I\_{t\_{u1}a\_2})I\_{t\_{a1}}, t\_{u\_{11}a\_1}l\_{a\_{11}} \rangle \rangle). \end$$

Note that, similar to the example decomposition and composition DMV SecANet, the full prefix words (*tu*2*a*<sup>1</sup> *ta*<sup>1</sup> *tu*1*a*<sup>2</sup> )*ta*<sup>2</sup> and *tu*1*a*<sup>1</sup> *ta*<sup>1</sup> encode the satisfiable and obstructed words, respectively.

#### **3.3.2 Resilience Extension: Modeling User Absence**

The elements of the SecANet+ approach could now also be further refined, so that, for example, it is ensured that there are no leftover tokens in the places of the newly combined nets after execution. Also, cycles could be encoded in isolated nets and combined in such a way that canceling and enacting the policy is possible. However, in order to illustrate the extensibility of the SecANet+ approach beyond the net constructions given so far, we sketch a net that could be used to encode user absence. As indicated in Chapter 2, user availability can be used to determine the resilience, and it plays an important role in the WSP context as well.

**Figure 3.67** Compact representation of user-availability net (A = Absence,P = presence) (with self-loop)

Figure 3.67 gives the graphical representation of an idea for a user-availability net that is supposed to take all three resilience levels introduced by Wang and Li [207] into account and the related initial markings.

• First, for static resilience, the idea is to create a place that indicates user presence (e.g., *pu*1*Present*) that is bidirectionally connected to all user-activity transitions of the same user. If this place does not have a token, which is then a precondition for the user-activity transition to be executable, it means that this user is not available. The self-loop could easily be avoided by adding a further place and transition (analogously to the "cancellation control" in Definition 3.69). The selfloop is neglected, because here only the basic idea of modeling is to be conveyed. Hence static resilience is represented in the state of the corresponding place, that is, the presence or absence of a token in the corresponding place directly encodes whether a user is present or absent.


Thus the net in Figure 3.67 would explicitly allow encoding of a user being available, being unavailable), or having come back. The transitions encoding user presence or absence would be represented in the language of the net as well. For instance, in order to encode a typical notion concerning resilience, namely *k*-resilience, where *k* is the number of absent users, the "absence transition" would have to be triggered for two users in the corresponding user-availability nets for *u*<sup>1</sup> and *u*2, for example, *tu*1*<sup>A</sup>* and *tu*2*A*. Based on the user-activity transitions, user-availability nets, as in Figure 3.67, could easily be integrated into a SecANet. They could then be combined with each user-activity assignment and the overall process by using the net synchronization operator.

In conclusion, SecANet+ allows not only taking constraints resulting from regulatory requirements or corporate governance into account but also considering restrictions resulting from the context or environment of a business, for example, user unavailability. When it comes to resilience, user availability also demands authorization, since not having access control would mean that any person would be allowed to execute the workflow tasks. Then the presence of a single user would trivially always suffice to execute the workflow.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **4 OLive-M: A SecANet Use Case for Model-Based Obstruction Solving**

If it is not possible to avoid an obstruction, and given that early process termination is not an option and that the business goal encoded by the process is still to be achieved, a method for completing an obstructed execution must be provided. This chapter introduces an approach called OLive-M to show that, on the basis of a SecANet, it is not only possible to capture obstructions but also to show how it can be applied to provide ways to resolve them. Thereby, to restore the liveness of an obstructed workflow execution caused by access control enforcement, a security-sensitive partial plan that completes the execution must be found. This approach will act within the general framework for requirements set up in Chapter 2; namely, on the basis of the captured state of an obstruction (GR-1), the obstruction is supposed to be resolved in a security-sensitive way based on indicators (GR-2), which are captured as costs. In the course of the approach, it will be depicted how all inputs that occur during the process lifecycle (i.e., model, policy, and log) are integrable (GR-3). This chapter presents a use case that demonstrates how, on the basis of a SecANet encoding, Petri net-related analysis techniques can be applied or "tweaked" to resolve obstructions.

Figure 4.1 shows the OLive-M approach. Here, an obstructed execution is supposed to live again based on a SecANet model. The requirements for such model- or specification-based solutions have been subsumed in "Requirements for specification-based completability (RSC)" in Chapter 2. To allow for obstructionresolving enforcement (RSC-1), partial plans that resolve obstructions must be generated. Therefore, the idea is to first "revive" the obstructed marking to escape the deadlock situation and obtain those plans. More specifically, to make the obstructed marking live again, tokens are supposed to be added to the places to enable transitions. Based on a marking that enables transitions; i.e., a live marking, a sequence of transitions that can complete the obstructed execution is to be found. Thereby, security-sensitive overrides (RSC-2) may take violations of the policy into account.

J. Holderer, *Obstructions in Security-Aware Business Processes*, https://doi.org/10.1007/978-3-658-38154-7\_4

**Figure 4.1** Overall OLive-M approach to resolve obstructions

The costs assigned to the considered places and transitions of the SecANet can be used to assess security-sensitivity. A minimal cost is assumed to provide the most security-sensitive solution. In a nutshell, the OLive-M approach involves two aspects: On one hand, adding tokens and computing the completion sequence from there, and on the other hand, determining the token addition and sequence with minimal cost. Such a completion sequence then represents a plan suitable for delegating the remaining tasks to users automatically (RSC-3). The obstruction is encoded using a SecANet, which can fully capture all specification-based information of relevance for the obstruction; i.e., the workflow, authorizations, constraints, users, and costs. Therefore, the solution can also be based on all relevant information to allow for an obstruction-aware completion (RSC-4).

A straightforward way to resolve an obstructed marking according to the described OLive-M approach would be to try out where an added token or tokens would lead to a live marking. Then a reachability graph could determine whether there is a reachable marking that contains the desired final marking. Thereby, the resulting costs of the added tokens and the transitions involved in the sequence of completion could be determined. However, for more extensive nets, because this method may face the problem of a state-space explosion, the "small" example SecANet can be resolved manually. Figure 4.2 shows a DMV SecANet with annotated costs and how the OLive-M approach can be applied. The highlighted costs are required to revive the obstructed marking and to complete the workflow. For example, on the basis of the obstruction marking {*p*2, *pt*2−}, adding a token to the SoD place as depicted in the net would allow escaping the obstruction marking because the resulting marking would then enable the transition *tu*1*t*<sup>2</sup> . However, adding a token to the SoD place would violate the SoD constraint, which is associated with a cost of *c* = 5.0. After firing *tu*1*t*<sup>2</sup> (*c* = 1.0) and *t*<sup>2</sup> (*c* = 1.0), this would result in a total cost of 7.0. This is obviously the only option to resolve the obstructed marking and reach the final marking {*po*} that makes sense here. For larger nets with a comprehensive workflow structure, multiple SoD places, more transitions, and differing costs, it can be assumed that more than one solution may exist. Here (one

**Figure 4.2** DMV SecANet with annotated costs and an added token in *pSoD* to escape the obstructed state

of) the least costly; i.e., the most security-sensitive solution, is then to be chosen. The examples, moreover, stress that interpreting the states of a SecANet is crucial here again. For example, adding a token to a constraint place that has already been in effect represents a violation. Also, adding a token in *pt*2<sup>+</sup> instead would contradict the overall interpretation of a SecANet. More specifically, an added token in *pt*2<sup>+</sup> would enable *t*2. Firing *t*<sup>2</sup> would skip the user-task assignment *tu*1*t*<sup>2</sup> and directly lead to the terminal marking {*pt*2−, *po*}. Hence, the place would indicate a user assignment even though no user has been assigned. The reductio ad absurdum of adding a token in *po* and claiming process completion would result in the marking {*pt*2−, *p*2, *po*}. It can be seen that in both cases, the leftover tokens in the terminal markings apart from *po* indicate an improper process completion. Therefore, the final marking that must be reached to complete the process must be defined in a way that excludes such unwanted solutions. In the example, the final marking {*po*} would take care of this. Based on these considerations, the following implications will be the keys to achieving the OLive-M approach.

• **Reaching proper final markings:** Solutions that resolve obstructions are supposed to be reasonable; i.e., the completion sequence must complete the obstructed execution from where the obstruction has happened. Hence, all unassigned WF tasks necessary to complete the workflow are supposed to be assigned to a user. Adding tokens to places that would allow skipping pending user-task assignments or tasks is not allowed. The definition of the final marking, which encodes process completion, is supposed to exclude such simple undesired solutions. Based on the further observation that obstructions may occur due to tokens missing in either SoD or BoD places, the addition of tokens must take these constrained places into consideration. Hence, given an obstructed marking, the question is which tokens must be added to reach a *proper* final marking that encodes the completion of the process.

• **Security-sensitive optimization:** The decision of which tokens to add to escape an obstruction, together with the decision of which path to choose that allows the execution to complete, must be optimized. Such an optimal security-sensitive solution represents an optimization problem, where the objective function is supposed to be a minimization that considers both the violations required to escape from the obstruction and the length of the task sequences required to complete the workflow. To solve such constrained optimization problems, local search, heuristics, or genetic approaches, and in particular, integer linear programming (ILP) are some of the most common methods.

This chapter first introduces the structural theory of Petri nets and then the context of ILP. That way, the setting of the approach can be described as a system of linear equations. Based on the theory that resolves such a system and finds a securitysensitive optimum, an ILP model that optimizes a marking equation and the costs associated with the SecANet will realize the OLive-M approach as a way to deal with obstructions. In contrast to computing a marking graph, this realization represents a "light technique" to resolve obstructions. The implementation of the approach will use experiments and discuss the results. Finally, in the course of the overall discussion of the approach, it will indicate how the OLive-M approach can be used to analyze satisfiability or resilience as well, which will show the versatility of the approach.

#### **4.1 Methods and Realization of the OLive-M Approach**

This section elaborates on the selection of Petri net analysis techniques to realize the OLive-M approach. These techniques should be capable of both determining how a certain final marking can be reached and of optimizing the solution. To illustrate their application, the selected techniques will be directly adapted and applied to theOLive-M context. The subsequent notation and terminology related to linear equalities or inequalities and (integer) linear programming (LP) are based on Schrijver [184].

#### **4.1.1 Structural Theory of Petri nets**

A Petri net system consists of both a net structure; i.e., the state variables (places) and their transformers (transitions), and a marking that represents a distributed overall state on the structure. The dynamics of the system or behavior are given by the evolution rules for the marking. On the basis of these two components, net-based models can be analyzed at two different levels: structural and behavioral. Structural reasoning allows the derivation of some "fast" conclusions about the possible behavior of the modeled system. Purely behavioral reasoning can be more conclusive but may require costly computations or may not even be feasible [186]. The three groups into which Petri net analysis is typically divided [155] are (1) the reachability (or also coverability) graph method, which explores the behavior, (2) the matrix-equation approach, and typically also (3) the reduction or decomposition techniques concern the net structure. The computation of the reachability graph involves essentially the enumeration of all reachable markings and applies to all classes of Petri net classes; however, it is limited to "small" nets due to the growing complexity of the state space. Particularly in light of this state-space explosion problem in behavioral analysis, structural methods are more appropriate for deducing whether a specific marking can be reached. Therefore, structural reasoning can be regarded as an abstraction of behavioral reasoning. For instance, instead of studying whether a given system, e.g., a net structure with an initial marking, has a finite state space, the system can be investigated to determine whether the state space is finite for every possible initial marking. Moreover, it can be investigated to determine whether there exists an initial marking that guarantees infinite activity rather than deciding this for a given marking [186]. Analogously, the main question of this chapter is not what markings could be reached, but whether a proper final marking is reachable from an obstructed state. Although structural reduction techniques and matrix equations are powerful, they often can be applied only to special subclasses of Petri nets or special situations [155]. Because the encoding of the SecANet is kept as simple as possible, and a SecANet represents an ordinary, plain, pure, and safe Petri net, it can be easily represented in a matrix as well.

Based on these considerations, the structural theory of Petri nets will subsequently be introduced to be used in the OLive-M approach. Here in particular, the addition of tokens, and the aim to search for firing sequences that lead to a proper final marking, point to the use of the so-called marking equation. This system of linear equations will then be adapted such that the OLive-M approach can be used.

First, basic matrix notations that allow the relation of the behavior and structure of a Petri net are given.

$$
\begin{array}{cc}
\mathbf{t}\_1 & \mathbf{t}\_2 \\
\mathbf{p}\_1 & \mathbf{0} \\
\mathbf{p}\_2 & \mathbf{0} \\
\mathbf{p}\_o
\end{array}
\begin{array}{c}
\mathbf{t}\_1 \\
\mathbf{0} \\
\mathbf{1} \\
\mathbf{0}
\end{array}
\begin{array}{c}
\mathbf{t}\_2 \\
\mathbf{0} \\
\mathbf{1}
\end{array}
$$

**Figure 4.3** Incidence matrix of DMV workflow net

**Definition 4.1 (Token conservation equations).** *Let N* = -*P*, *T* , *F*, *m*0 *be a Petri net. Given a feasible sequence m*<sup>0</sup> σ → *m, the number of tokens for a place p in m is equal to the tokens of p in m*<sup>0</sup> *plus the tokens added by the input transitions of p in* σ *minus the tokens removed by the output transitions of p in* σ*:*

$$m(p) = m\_0(p) + \sum\_{t \in \mathfrak{p}} |\sigma|\_t \, \mathcal{F}(t, p) - \sum\_{t \in p^\bullet} |\sigma|\_t \, \mathcal{F}(p, t)$$

**Definition 4.2 (Incidence matrix of a Petri net).** *The matrix* **N**(*p*, *t*) *which is defined by F*(*t*, *p*) − *F*(*p*, *t*) *is called the incidence matrix of N.*

Figure 4.3 gives an example of the incidence matrix of the DMV workflow net. Figure 4.4 shows the incidence matrix of the structurally more complex SecANet.

**Definition 4.3 (Parikh vector).** *Let* σ *be a feasible sequence of transitions of N.* |σ|*<sup>a</sup> represents the number of occurrences of a in* σ*. The Parikh vector is a function*: *<sup>T</sup>* <sup>∗</sup> <sup>→</sup> <sup>N</sup>*<sup>n</sup> defined as* <sup>σ</sup> <sup>=</sup> (|σ|*t*<sup>1</sup> ,..., <sup>|</sup>σ|*tn* )*. For simplicity,* <sup>|</sup>σ|*ti will also be represented as* σ (*ti*)*. The support of a Parikh vector* σ*, denoted by* supp(σ ) *is the set* {*ti*|σ (*ti*) > <sup>0</sup>}*.*

**Figure 4.4** Incidence matrix of DMV SecANet

**Definition 4.4 (Linear Equality).** *A* linear equality *is given by a row vector <sup>a</sup>* <sup>∈</sup> <sup>R</sup>*n, a vector of variables x, and a real value b. It is represented by*

$$a^\top \cdot x = b$$

*and it is* feasible *if there exists some assignment k* <sup>∈</sup> <sup>R</sup>*<sup>n</sup> to x satisfying a* · *k* = *b.*

**Definition 4.5 (System of Linear Equalities).** *A* system of linear equalities *is a set of linear equalities. It is* feasible *if there exists a vector that satisfies all equalities of the set. If it is finite, it has a matrix-based representation*

$$
\mathbf{A} \cdot \mathbf{x} = b \,,$$

*where the vectors a of the linear equalities are the rows of the matrix* **A***, and the numbers b are the components of the vector b.*

Based on these definitions, the marking equations for all the places in the net can be written in the following matrix form (see Fig. 4.5c for an example): *<sup>m</sup>* <sup>=</sup> *<sup>m</sup>*<sup>0</sup> <sup>+</sup>**N**·σ, where **<sup>N</sup>** <sup>∈</sup> <sup>Z</sup>*P*×*<sup>T</sup>* is the *incidence matrix* of the net: **<sup>N</sup>**(*p*, *<sup>t</sup>*) <sup>=</sup> *<sup>F</sup>*(*t*, *<sup>p</sup>*) <sup>−</sup> *<sup>F</sup>*(*p*, *<sup>t</sup>*).

**Definition 4.6 (Marking Equation).** *If a marking m is reachable from m*0*, there exists a sequence* σ *such that m*<sup>0</sup> σ → *m and the following system of equations has at least the solution X* <sup>=</sup> σ*:*

$$m = m\_0 + N \cdot X \tag{4.1}$$

If equation (4.1) is not feasible, *m* is not reachable from *m*0. The inverse does not hold in general: there are markings satisfying equation (4.1) which are not reachable. Those markings are said to be *spurious* [186]. Figures 4.5a-c show an example of a net with spurious markings. The Parikh vector<sup>σ</sup> <sup>=</sup> (2, <sup>1</sup>, <sup>0</sup>, <sup>0</sup>, <sup>1</sup>, <sup>0</sup>) and the marking *m* = (0, 0, 1, 1, 0) are a solution to the marking equation, as shown in Figure 4.5c. However, *m* is not reachable by any feasible sequence. Figure 4.5b depicts the graph containing the reachable markings and the spurious markings (shadowed). The numbers inside the states represent the tokens at each place (*p*1,..., *p*5). This graph is called the *potential reachability graph*. The initial marking is represented by the state (1, 0, 0, 0, 0). The marking (0, 0, 1, 1, 0) is reachable from the initial state only by visiting a negative marking through the sequence *t*1*t*2*t*5*t*1, as shown in Fig. 4.5b. Therefore, equation (4.1) provides only a sufficient condition for the reachability of a marking and the replayability for a solution of equation (4.1).

For well-structured Petri nets, for example when nets are *free-choice* [155], *live*, *bounded* and *reversible*, equation (4.1) together with a collection of sets of places (*traps*) of the system completely characterizes reachability [76]. For the rest of cases, the problem of the spurious solutions can be palliated by the use of trap invariants [89], or by the addition of some special places named *cutting implicit places*[186] to the original Petri net that remove spurious solutions from the original marking equation. Concerning matrix equations, it is assumed that a Petri net is pure or is made pure by adding a "dummy pair" of a transition and a place, as discussed previously, to avoid self-loops [155].

To realize theOLive-M approach, the marking equation is applied in the following way. First, on the basis of the obstructed marking, tokens must be added to make the marking live again. In a second step, the Parikh vector then can be computed to give the Parikh representation of the completion sequence. The marking equation is adapted accordingly:

**Definition 4.7 (OLive-M State Equation).** *Let NSecANet be an obstructed SecANet, with a corresponding obstruction marking m*⊗*. Then, if there exists at least one transition t* ∈ *TSecANet that can be enabled by the addition of a marking m* ∈ *PSecANet to m*⊗*; i.e., the resulting marking mli*v*<sup>e</sup>* ≥• *t, the following system of equations has at least the solution* = *m:*

$$m\_{live} = m\_{\otimes} + \Delta \tag{4.2}$$

*If a marking mend is reachable from mli*v*e, there exists a sequence* σ *such that mli*v*<sup>e</sup>* σ → *mend and the following system of equations has at least the solution <sup>X</sup>* <sup>=</sup> σ*:*

$$m\_{end} = m\_{live} + \mathbf{N} \cdot X \tag{4.3}$$

**Figure 4.5** (a) Petri net. (b) Potential reachability graph. (c) Marking equation

**Figure 4.6** OLive-M state equations applied on an obstructed DMV SecANet. Each placerelated variable of (e.g., *pi*) denotes the number of tokens to be added to the corresponding place. Each transition-related variable of *X* (e.g., *t*1) denotes the number of occurrences of the corresponding transition in the resulting Parikh vector

**Example Solution of the OLive-M State Equation:** There are various methods to solve systems of linear equations. Probably the most well-known algorithm in linear algebra is the Gaussian elimination method, which is a polynomial-time method for solving a system of linear equations [114, 184]. Solving the system of linear equations in Figure 4.6 that applies the OLive-M marking equation to the example SecANet results in the solution

$$\begin{aligned} t\_1 &= p\_i \\ t\_2 &= p\_i + p\_2 + 1 \\ t\_{u\_1 t\_1} &= -p\_i - p\_2 + p\_S + p\_{SoD} - 1 \\ t\_{u\_2 t\_1} &= 2p\_i + p\_2 - p\_4 - p\_S - p\_{SoD} + 1 \\ t\_{u\_1 t\_2} &= p\_i + p\_2 - p\_S + 1 \\ p\_3 &= -p\_i - p\_2 \\ p\_6 &= p\_i - p\_4 \\ p\_o &= p\_i + p\_2 - p\_S \end{aligned}$$

Based on the observation that one can restrict the addition of tokens to constraints, one could boil the possible solutions down considerably by setting all place variables that do not encode a constraint to zero. In the example, this results in the solution

$$\begin{aligned} t\_1 &= 0 \\ t\_2 &= 1 \\ t\_{\mathfrak{u}\_{1f1}} &= p\_{SoD} - 1 \\ t\_{\mathfrak{u}\_{2f1}} &= -p\_{SoD} + 1 \\ t\_{\mathfrak{u}\_{1f2}} &= 1 \\ p\_o &= 0. \end{aligned}$$

Because the values of *X* and are supposed to be natural numbers, here there is only one solution, namely *pSoD* = 1; i.e., to escape the obstruction marking, *pSoD* is additionally marked with a token. Based on this, the elements of the corresponding Parikh vector *X* can be determined. Figure 4.7 shows this variable assignment that solves the OLive-M state equation applied to the example DMV SecANet. Figure 4.8 shows the same solution graphically, which obviously corresponds to the solution found manually for Figure 4.2 above.

**Figure 4.7** OLive-M state equation *mli*v*<sup>e</sup>* = *m*<sup>⊗</sup> + (token(s) to add) and *mend* = *mli*v*<sup>e</sup>* + **N** · *X* (Parikh vector of completion sequence) to resolve the obstruction in DMV SecANet

**Figure 4.8** (added tokens) and *X* (Parikh vector of completion sequence) to escape the obstructed state

**Replayability of Solutions:** Based on the fact that the solutions of the marking equation can be spurious, it may not be possible to reach the final marking with a proposed solution; i.e., there is no respective firing sequence. Therefore, the replayability of each solution must be checked. This means that because the solutions provided by the *X* vector do not provide the real ordering of transition executions, all possible linearizations must be explored to assess whether a solution obtained denotes a real sequence (in some of its possible linearizations). Due to the simplicity of the example, the order in which the transitions encoded in *X* must be executed is obvious, namely, *tu*1*t*<sup>2</sup> *t*2.

#### **4.1.2 Linear Programming**

The solution of the simple example in Section 4.1.1 suggests that the solution of the system of linear equations encoding the OLive-M state equation does not propose a specific solution for and *X*. The number of variables in the vectors *X* and exceeds the number of linear equations, which indicates that a solution itself probably contains variables again. Hence, rather, the solution results in further linear equations, which builds the constraints of an optimization problem that is supposed to then find specific variable assignments of natural numbers. Here, with regard to security-sensitive optimization, LP seems particularly appropriate. It not only allows the solution of systems of linear equalities but also considers linear inequalities, also called constraints. Therefore, it is possible to take an objective function into account that can be used to find an optimal solution for the constraints given. That way, the decision on which tokens to add and which transitions to fire to achieve process completion will be embedded into a constrained optimization problem.

**Definition 4.8 (Linear inequality).** *A* linear inequality *or* constraint *is given by a row vector a* <sup>∈</sup> <sup>R</sup>*n, a vector of variables x, and a real value b. It is represented by*

$$a^\top \cdot x \le b$$

*and it is* feasible *if there exists some assignment k* <sup>∈</sup> <sup>R</sup>*<sup>n</sup> to x satisfying a* · *k* ≤ *b.*

**Definition 4.9 (System of Linear Inequalities).** *A* system of linear inequalities *is a set of linear inequalities. It is* feasible *if there exists a vector that satisfies all inequalities of the set. If it is finite, it has the matrix-based representation*

$$A \cdot x \le b \,,$$

*where the vectors a of the linear inequalities are the rows of the matrix* **A***, and the numbers b are the components of the vector b.*

**Definition 4.10 (Linear Programming Problem).** *A LP*problem *is a system A* · *x* ≤ *b of linear inequalities, and optionally a linear function c* · *x called the* objective function*. A solution of the problem is a vector of rational numbers that satisfies the constraints. A solution is* optimal *if it minimizes the value of the objective function (over the set of all solutions). An LP is* feasible *if it has a solution.*

**Definition 4.11 (Integer Linear Programming Problem).** *An ILP is an LP where the set of solutions is given by vectors of integers only; i.e., it is* feasible *only if there exists some assignment k* <sup>∈</sup> <sup>Z</sup>*<sup>n</sup> to x satisfying <sup>A</sup>* · *<sup>k</sup>* <sup>≤</sup> *b.*

The complexity of solving a linear problem depends on the domain under consideration. Specifically, it is known [184] that:


Based on these definitions, LP is not only suitable to resolve the OLive-M state equation for an obstructed SecANet, it may be used directly to minimize the costs associated with the nodes of a SecANet to find a security-sensitive solution. Because the algebraic representation of Petri nets is based on integers, and the envisaged approach to add tokens and find a completion sequence implies integers (the tokens in are supposed to be natural numbers, as well as the transitions in *X*, which can only be fired entirely or not at all), the subsequent approach will directly apply an ILP model accordingly.

**OLive-M Realization by the Marking Equation and ILP:** Given an obstruction marking *m*<sup>⊗</sup> and a final marking *mend* , the marking equation *m* = *m*<sup>0</sup> + **N** · *X* may provide the Parikh vector *X*, indicating which transitions must be fired to reach the final marking. To enable the transitions proposed by *X*, first, a live marking must be reached by adding tokens from variable to the obstructed marking. With the help of a cost function *cost*(*X*, ) considering sequence length, the number of tokens, and user-defined costs (e.g., for security violations), an optimized solution with minimal cost for *X* and is supposed to be proposed. The ILP model below shows the approach for using the marking equation:

★ ✧ ILP model for completing an obstruction state *m*<sup>⊗</sup> Min cost(*X*, ) subject to: *mli*v*<sup>e</sup>* = *m*<sup>⊗</sup> + *mend* = *mli*v*<sup>e</sup>* + **N** · *X <sup>X</sup>*, <sup>≥</sup> **<sup>0</sup>** *<sup>X</sup>* <sup>∈</sup> <sup>N</sup>|*<sup>T</sup>* <sup>|</sup> <sup>∈</sup> <sup>N</sup>|*P*<sup>|</sup>

✥

✦

After an obstructed marking *m*<sup>⊗</sup> has been reached, the necessary tokens will be added to the deadlocked model to take the current obstructed marking to a final state. The ILP model above has two sets of variables, according to the equations (4.2) and (4.3): is the addition of tokens to *m*<sup>⊗</sup> that takes to an unobstructed marking *mli*v*e*, and *X* is the Parikh vector that will take from *mli*v*<sup>e</sup>* to *mend* . A solution to the ILP model will then jointly decide the necessary number of tokens and the consequent firings to be made to reach *mend* . Remarkably, the cost function is a minimization that considers both the length of the sequence completing the workflow (through the Parikh vector *X*) and the number of tokens required to escape from the obstruction marking (the variables ), thus globally optimizing these two decisions. This thesis considers the cost as a user-defined function because, on the basis of different indicators, different costs could be assigned depending on the context; e.g., if the shortest path is preferred independent of the violations done, then one can set the variables' cost to 0 (or substantially less than the *X* variables). On the other hand, if the number of violations should be reduced, the opposite cost can be set. Also, the cost for variables in the *X* vector may differ if, e.g., the firing of certain activities should be incentivized or avoided. The same holds for the variables.

For instance, for the Petri net in Figure 3.24, analogously to the example solution before, the given ILP model (assigning unitary costs to both *X* and ) will find the solution = (0, 0, 0, 1, 0, 0, 0, 0) (i.e., putting a token in the *SoD* place) and *X* = (0, 1, 0, 0, 1) (with *X* according to the sequence *t*1, *t*2, *tu*1*t*<sup>1</sup> , *tu*2*t*<sup>1</sup> , *tu*1*t*<sup>2</sup> ). Assuming that the costs associated with transitions are normally > 0, minimizing the costs of cyclic nets means that loops are avoided as far as possible. This then incentives that the process execution successfully completed as immediately as possible. The assignment on and *X* variables defines the violations to make in order to complete the workflow. Ways to assess the impact and meaning of these violations in terms of security-sensitivity for the authorization, constraints, and users will be the subject of the discussion of the approach in Section 4.3.

#### **4.2 OLive-M Experiments for Model-Based Obstruction Solving**

The implementation of the realization of the OLive-M presented above was applied to the CEW SecANet shown in Figure 3.46.

#### **4.2.1 Implementation**

The implementation of the OLive-M obstruction solution bases on a Python implementation by Taymouri [198, 197] and uses Gurobi [100] as the ILP solver. The experiments were run on a MacBook Pro with 8 GB RAM and an Intel Core i7 3 GHz CPU. Based on an SecANet input file in PNML standard format the the optimal solution is returned as a list that contains an encoding of the and *X* vectors.

To assign costs in the implementation, the Petri net type definition (PNTD) of place/transition nets (P/T nets) was extended with the optional addition of costs to places or transitions, resulting in P/T cost Petri nets (P/TCost-nets)1. This PNTD redefines the value of P/T-nets with costs for places and transitions and inherits the marking and annotations from the official PNML P/T-net definition.

#### **4.2.2 Remarks on Costs and Results**

Note that no matter how costly, there may be places to which a token must be added to reach the final marking constraint (e.g., the SoD place in the DMV SecANet example). If there is a choice among multiple transitions or places (e.g., multiple SoD places to violate) to reach the final marking, the different costs assigned are crucial. The implementation can handle both unitary and differing costs. The optimal solution is obtained when the constraint regarding the proper final marking is satisfied. In general, the ILP solutions provided in the experiments are not unique. It is possible to have many optimal solutions, and all of them are correct.

#### **4.2.3 Experiment Preparation**

To allow the final marking to be determined only by the output place, further cancellation transitions were introduced at the end of the process. They consume all the remaining tokens in the places that were put on top of the initial workflow before the flattening; i.e., (un)assignment, SoD/BoD, and their corresponding capacity-1-complement places. Therefore, similar to the introduction of the re-enactment constructions to deal with loops, or, at the end of the SecA-WF-Net encoding in Chapter 3, a transition "reach\_end" was added just before the end place *po*. Firing this transition produces a token into a place to which all cancellation transitions are connected. That way, this construction allows the cancellation of remaining tokens

<sup>1</sup> https://github.com/iig-uni-freiburg/SEPIA/blob/ptcnet/res/pntd/ptcnet.pntd

if required. In this way, the obstruction marking could be changed without the necessity to consider changes in the final marking; in particular, changes in the marking for the places resulting from the flattening.

#### **4.2.4 Experiment Setup and Solution**

The tool was able to provide a solution based on the net in Figure 3.46 with unitary costs assigned (cost = 1.0 for each place and transition) and given an arbitrary obstruction marking and a final marking to reach. To demonstrate this, an interesting obstruction marking could be reached after executing the following sequence:

σ<sup>⊗</sup> = *ts*, *tm*<sup>1</sup> , *t <sup>f</sup>*<sup>1</sup> , *tdt*<sup>1</sup> , *t*1compute market value , *tat*<sup>2</sup> , *t*2control computation , *t*Computation correct?yes, *to*<sup>3</sup> , *tbt*<sup>3</sup> , *t*3Evaluate Safeguarding Requirements, *t*Safeguarding Required?yes, *tbt*<sup>4</sup> , *t*4Prepare Safeguarding , *tm*<sup>2</sup> , *tj*<sup>1</sup>

The obstruction marking resulting from this sequence is shown below, listing only places that contain *m*(*p*) > 0. For reasons of clarity, the marked places (with *m*(*p*) = 1) are categorized:

Workflow places: *Pj*1,*t*<sup>5</sup>

*SoDplaces* : *SoDct*1*t*<sup>2</sup> , *SoDat*5*t*<sup>1</sup> , *SoDdt*5*t*<sup>3</sup> , *SoDdt*5*t*<sup>4</sup> , *SoDdt*5*t*<sup>2</sup>

*C*1*C places* : *SoDat*1*t*2*c*1*<sup>c</sup>* , *SoDdt*1*t*2*c*1*<sup>c</sup>* , *BoDbt*3*t*4*c*1*<sup>c</sup>* , *BoDdt*3*t*4*c*1*<sup>c</sup>* , *SoDat*5*t*2*c*1*<sup>c</sup>* , *SoDdt*5*t*1*c*1*<sup>c</sup>*

The solution provided required that a token be put into *SoDat*5*t*<sup>2</sup> on the basis of and provided the Parikh vector *X* containing the following transitions2:

```
tApproved?yes, treach end, tat5 , tApprove Acquisition, te
```
However, running the tool again on the same obstruction marking and net provided a different optimal solution, namely adding one token into *SoDdt*5*t*<sup>1</sup> and firing a sequence containing the following transitions:

*t*Approved?yes, *t*reach end, *tdt*<sup>5</sup> , *t*Approve Acquisition, *te*

<sup>2</sup> The cancellation transitions are omitted here for the sake of clarity.

Hence, the approach obtained multiple correct solutions. The replayability for both of the Parikh vectors on the net was successfully checked with an extension to the same tool.

#### **4.2.5 Experiments with More Extensive Nets**

The same net was then concatenated step by step (again with equal costs) up to six times (see Figure 4.10 for an impression of the sixth concatenation) and encoded the obstruction marking above into it. For all cases, the solution proposed the addition of a token into either *SoDat*5*t*<sup>2</sup> or *SoDdt*5*t*<sup>1</sup> .

More specifically, the obstruction marking was always encoded in the first of the concatenated nets. Therefore, in particular, the solutions assigning values to the *X* vector to reach the final marking increased.

Table 4.1 shows the statistics of the ILP that was solved 3. Gurobi also computed the corresponding costs. Note here that transitions in the computed solution can happen multiple times because of cycles in the net. However, as indicated before, the occurrence of loops is minimized in the course of the optimization. Figure 4.9 shows a perfect linear relation between the execution time required and the size of the problem.


**Table 4.1** ILP statistics

<sup>3</sup> The related process models can be consulted at https://doi.org/10.6094/UNIFR/228177. The archive file olivem.zip includes a manual that explains how to reproduce the results.

**Figure 4.9** Experiment runtimes

#### **4.2.6 Replayability**

Because the solutions provided by the *X* vector do not provide a real ordering of transition executions, all possible linearizations were explored to assess where a solution obtained denoted a real sequence. This checking could be done for only the first four experiments because for the rest the exploration of possible solutions was very large. It is remarkable that for these four models, the solutions obtained represent a real sequence; i.e., there was a replayable linearization in the model.

#### **4.2.7 Obstruction Position**

To determine whether the position of the obstruction in the net affected runtime, an obstruction was incorporated into the last of the six concatenated nets (cf. Figure 4.10). The regarded net with 911 variables took 0.725 seconds to be solved, although the solution contained only 18 variables instead of 188. Hence, there were no substantial runtime differences from the same net with the same size but different positions of the obstruction marking.

#### **4.2.8 Differing Costs**

In a further experiment, various costs were assigned to *SoDdt*5*t*<sup>1</sup> (cost = 3.0) and *SoDat*5*t*<sup>2</sup> (cost = 5.0) to the net from the first experiment (with 151 Variables). Consequently, then the second solution containing *SoDdt*5*t*<sup>1</sup> became the only solution, resulting in a total cost of 32.0. Hence, the proposed solution was the most security-sensitive with the lowest cost.

#### **4.3 Discussion and Potentials of the OLive-M Approach**

Based on the conclusions and requirements from Chapters 1 and 2, this chapter addresses the obstructions that must be handled at runtime to restore the liveness of an obstructed process execution. Based on the given representation of the problem, possible solutions were identified. Finally, the solution, namely OLive-M, to finding a security-sensitive solution to complete the obstructed execution was deduced. By encoding the obstruction with a corresponding marking, the marking equation was used to provide a minimized Parikh vector to reach a completed marking, which if it is fired from the obstruction state, violates the firing rules. That way, on the basis of the model of a workflow and its authorizations and constraints, an obstructed state was solved not by changing the semantics of the model [25], but by finding the best path in the given model with minimal violation. Thereby, the language of a SecANet is temporarily extended by the words resulting from the obstructed sequences and the appended sequence that completes the obstructed execution. This solution allows the enforcement of an obstruction-resolving (RSC-1) in a security-sensitive way (RSC-2). In addition to the minimization of the solution, a certain threshold of security sensitivity could moreover exclude proposed solutions, because depending on the severity of the violations, it may be less risky to abort the process than to resolve the obstruction for an unjustifiable cost. The plans obtained to resolve obstructions could be realized automatically by delegation (RSC-3). For example, they could be used to recommend who should do which tasks in a breakglass situation, or as an assisted delegation, showing to the delegator potential best delegates (with the least violations). In all of this, the SecANet allowed searching for solutions that were fully aware of the obstruction (RSC-4). Although these requirements have thus been addressed to a certain extent, subsequent discussions of different aspects will point out the limitations but also the further potential of the presented approach.

**Figure 4.10** Impression of six concatenated nets

#### **4.3.1 Limitations in Solutions**

Based on the objective function that considers the costs assigned to the places and transitions and the calculated total cost, solutions can be identified as optimal; i.e., minimal. However, based on the fact that the solutions of the ILP can be spurious regarding their marking, and hence spurious in reaching the final marking, it may be possible for a solution to be minimal but at the same time not able to reach the final marking; i.e., there would be no respective firing sequence based on the given Parikh vector *X*. Hence, the solutions have the limitation that they do not necessarily represent the minimal violations required to reach the proper final marking. Here, results could be investigated further to trade efficiency for precision; i.e., by incorporating ordering constraints in the marking equation. Moreover, because the existence of a firing sequence based on a Parikh vector is guaranteed only for weakly sound-bounded free-choice models, and not for more general Petri net classes, the SecANet free-choice transformation identified in Chapter 3 could be further pursued here.

#### **4.3.2 Efficiency**

OLive-M represents a "light" technique to resolve obstructions as structural methods are more efficient than reachability analyses. In particular, the matrix equation itself can be solved in polynomial time. Computing the ILP and replay may be inefficient for larger instances. However, smaller-sized ILP instances can be solved efficiently in practice. Because a SecANet represents a plain, safe, and pure ordinary Petri net, the structural theory can be easily applied, with the data reasoning remaining mild. Although a SecANet is, e.g, not free-choice, the experimental results speak well for the SecANet (see Figure 4.9). Here, one could further customize the approach with regard to the SecANet application by further refinements or simplifications. If ones assumes that only constraints may be violated by adding tokens one would not have to consider all other places for the addition of tokens such that the variables in the matrix equation, the number of possible solutions, and the complexity would be reduced. However, a comparison between Figures 4.3 and 4.4 indicates how the structural complexity of the SecANet approach is a tradeoff for efficiency, which indicates the greater amount of space that is used for the SecANet approach. As shown above (cf. Chapter 3), a free-choice transformation would further increase the structural complexity of the SecANet. With regard to the replay, just replaying all possible linearizations of the solutions could, in the worst case, result in exploring all reachable markings. In contrast, given the marking equation and a free-choice net, the solution cannot be spurious and can be found in polynomial time.

#### **4.3.3 Replayability**

To determine replayability, the experiment basically tried to replay all possible linearizations of the Parikh vector on the SecANet. This, however, was a very simple and exhaustive way to check replayability, as indicated by the fact that only the replayability of the first four nets could be checked. Here, instead of checking whether every possible linearization of the Parikh vector is repayable, a more efficient way to check replayability would be to take the model into account. For example, given a Parikh vector that includes the transitions *tu*1*t*<sup>2</sup> and *t*2, if the model always starts with *tu*1*t*<sup>2</sup> , there would be no need to try linearizations that start with *t*2. That way, an exploration algorithm could try to fire all transitions in the Parikh vector and thereby change the marking. In case there are several options of which transitions to fire based on the model, the algorithm could backtrack to what extent branches could be further replayed. More sophisticated techniques in this respect can be found in, for example, the works of Taymouri and Carmona [199]. Their replayability checks operate in the context of the computation of model trace alignments for conformance checking (cf. Chapter 2 on Process Mining), but could certainly be adapted to the SecANet context as well.

#### **4.3.4 Emergency-SecANet**

In contrast to the basic DMV SecANet example, the solutions of the CEW SecANet show that multiple solutions with various violations of constraints are possible. However, there may also be only one constraint, as in the DMV SecANet that can be violated such that the solution *must* involve the violation of that particular SoD constraint at no matter what cost. However, in a critical situation; for example, an emergency, there may still be further possibilities in the context of the processes that are not captured in the normal process specification. Therefore, to provide for more solutions to escape obstruction, one may consider not only violating constraints but also escalating user privileges or even introducing new users in the widened context of potential process participants. To address such exceptional situations, a so-called "emergency SecANet" could be defined. Such a net could then be used only in case an obstruction were entered. It would allow authorizing a user to a task that was not authorized in the initial policy and thus permitting further user-

**Figure 4.11** "Emergency-SecANet" with costly additional user-task assignment *tu*3*t*<sup>2</sup> that could be used to resolve the obstruction too

task assignments. Figure 4.11 shows such an additional user-task transition for the second tasks. Adding such a user could then be connected to a certain cost for, for example, the associated risk of privilege escalation. Alternatively, adding further user-task transitions could, for example, encode superuser rights. Further optional elements could be built into the SecANet in that way as well; e.g., additional constraint places. Thereby, the obstruction marking could easily be transferred to the emergency SecANet containing further net elements. Therefore, it would be important to allow only the additional constraints to contain a token, such that no existing constraints were enacted again. As a solution to resolve an obstruction in such an emergency SecANet could then foster empowering users who were not authorized before, instead of taking a too-high violation of an SoD constraint into account. In this way, a SecANet could be used to integrate break-glass scenarios and directly assess the best security-sensitive solution. This could also be developed to the point where a so-called "compensation task" would be introduced that even reduces costs; e.g., a task to review the affected case could have a negative cost assigned.

In conclusion, the main purpose of the OLive-M approach is to demonstrate a use case where, on the basis of a SecANet, Petri net-based techniques can be used to find solutions to complete an obstructed state. Based on the considerations, the marking equation and ILP method were chosen to propose solutions to complete the workflow. Beyond the limitations and possibilities of the OLive-M approach, the matrix representation may also be used not only for solving obstructions but to help detect obstructions. More specifically, on the basis of the structural patterns in the SecANet encoding, one could also investigate whether there were certain structural patterns in the matrix representation in the SecANet—for example, in the incidence matrix—that could reveal obstructions beforehand, and that way simplify their detection. However, on the basis of the plethora of techniques that exist for or relate to Petri nets, the SecANet encoding certainly builds the basis for further approaches that would resolve obstructions differently. Here one could, for example, allow the reversal of markings, and by that search for reachable markings from the initial marking that come the closest to the obstruction marking and still allow for process completion. Because these reachable markings would belong to full firing sequences that would end in the desired final marking, this could save checking replayability. Or, one could search for firing sequences that are closest to the obstructed sequence and in that way search for the least distant or best aligning alternative path that is exceptionally allowed to resolve the obstructed state. Thereby, both approaches could incorporate costs as well. In fact, the latter can be compared to the approach idea in the next chapter, which will be considered with regard to the log-based resolving of obstructions. As identified in Chapter 2, indeed, based on the general framework for requirements (GR) embedded in all SecANet-related solutions and also the policy and the model, the log may be considered as well to allow the consideration of all inputs (GR-3). It could be applied to the OLive-M approach as well by deriving indicators, such as resource behavior indicators. In the sense of the aspired indicator-based security, these indicators could then also be incorporated in the costs assigned to the SecANet elements, and thus enhance the SecANet model.

#### **4.3.5 Extending the OLive-M Principle to Analyze Satisfiability and Resilience**

The two parts of the OLive-M principle, namely adding tokens and completing the execution in an optimal way, may have further applications. In the context of this work, and on the basis of the SecANet encoding, it will subsequently be shown how the OLive-M realization can be used to analyze satisfiability and resilience. Here, the graphical nature of the SecANet particularly would allow the direct identification of weak spots in an unsatisfiable WSP instance. Moreover, the marking equation could be used to propose which users to add to make a workflow executable. Therefore, the notion of cost can be seen in a broader context because not only securitysensitive costing may be required, but also the costs of having employees available and assigned to a certain process.

#### **4.3.5.1 Analyzing Satisfiability**

Similar to the capture and detection of obstructions, an unsatisfiable workflow raises the question as to where exactly its weak point is; for example, to identify how authorization policies or the user base must be changed to allow for a valid execution plan. Therefore, the principle of the OLive-M approach can be adapted to the context of WSP solving in a way that allows (even graphically) the identification of such weak spots in workflows and their authorization constraints by the use of Petri nets.

More specifically, on the basis of a start marking *mstart* and a final marking *mend* , the marking equation *m* = *m*<sup>0</sup> + **N** · *X* can be used to find the Parikh vector *X*, indicating which transitions must be fired to reach the final marking. If the policy specification cannot provide a valid plan; i.e., no firing sequence can reach the final marking, a live marking must be reached by adding tokens from variable to the start marking. Analogously to the ILP model above, with the help of a cost function *cost*(*X*, ) considering sequence length, the number of tokens, and user-defined costs (e.g., for adding staff), an optimized solution with minimal cost for *X* and is proposed. The ILP model below sketches the approach:

```
★
✧
                                                        ✥
                                                        ✦
   ILP model to find a firing sequence from mstart
              Min cost(X, ) subject to:
                 mlive = mstart + 
                 mend = mlive + N · X
                 X,  ≥ 0 X ∈ N|T |  ∈ N|P|
```
Hence, if there were a valid plan or firing sequence, no further tokens need be added; i.e., = **0**, and *X* would contain only the transitions that must be contained in the firing sequence. In contrast, if is not empty (or **0**), this means that the workflow is not satisfiable. then already indicates the weak spot of the policy; namely, for example, which user is missing at which task or which constraint is the foremost cause of the unsatisfiability. That way provides an insight as to where the "bottleneck" occurs in the security-aware process. Here, a more in-depth evaluation could be further pursued that considers the efficiency of the ILP solution compared to that of the usual WSP techniques; e.g., based on SAT-Solvers. Eventually, such a satisfiability analysis technique providing a (graphical) representation of authorizations and workflow in one model could help policy designers to pinpoint deficits in the policy specification causing the unsatisfiability.

#### **4.3.5.2 Analyzing Resilience**

Another line of research could be devoted to estimating resilience by using the structural theory of Petri nets. That way, a minimal amount of users required to successfully complete a workflow could be estimated, which would provide insight into the resilience of the workflow. Based on the presented idea to extend the approach with user-availability nets (cf. Section 3.3.2 on SecANet+), a SecANet could involve the encoding of user availability. Here, finding for instance the minimal amount of users to execute a workflow could be done by using the marking equation as well. More specifically, the "ILP model to find a firing sequence from *mstart* " (see Section 4.3.5.1) for satisfiability analysis could be used because, in the resilience setting, based on the initial marking, the final marking is supposed to be reached as well. The difference would lie in the SecANet, which is extended by the user-availability encoding. Analogously to the ILP model for satisfiability, adding tokens to the places that indicate users' presence, is then supposed to indicate which users to add by the tokens in the places encoding user presence to make the process executable. Such an ILP model could then be used to compute various resilience levels introduced at the end of Chapter 3. The -based approach would address primarily the static version of resilience. However, one could also consider the *X* vector for decremental or dynamic resilience and associate the costs of the respective transitions. This would cause user absence or user presence with positive or negative costs such that, for example, there would be incentives to make sure that users only must be there as long as they are required to run the process (so that making users absent would have a negative cost). That way, the structural theory could be used to actually propose where tokens; i.e., users, must be added () and when users could become present or absent (*X*) to make a workflow resilient. Thereby, depending on the respective costs or risks that adding or removing personnel would mean in reality, adding users and changing user availability could be promoted or prevented.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **5 OLive-L: A SecANet Use Case for Log-Based Obstruction Solving**

In a metaphorical sense, event logs are a "force of the past" [159] that can be used to shape the present and predict future events. Similarly, in the context of this thesis, past process executions are intended to eliminate a present obstruction and predict the sequence of events for how the process execution can be completed (cf. the Log-based Completability Requirements in Chapter 2.3). In addition to the model-based approaches, this chapter assumes there is historical information for detecting and resolving obstructions. The consideration of logs addresses the general requirements of completability to consider all inputs (model, policy, log) throughout all approaches (GR-3). Similar to the obstructed path sequences of process models, obstructed traces represent obstructed states (GR-1). As identified in Chapter 2.3, various log-based techniques exist to derive a range of indicators to consider when assessing the security-sensitivity of solutions (GR-2).

Analogously to the model-based OLive-M approach, this chapter presents OLive-L to make obstructed sequences live again based on the log. The log-based completability requirements derived in Chapter 2.3, representing the potentials for how logs can be used in the context of obstructions, are incorporated.

Leveraging this approach, this chapter presents a further use case of the SecANet encoding to demonstrate its applicability to log-based techniques. Although the SecANet approach forms the basis, OLive-L works independently because, depending on the information system used to execute a process, the process model or policy is not necessarily provided or enforceable, and only logs are available. However, the approach also leverages SecANet modeling, which is relevant in additional aspects, such as generating or classifying logs.

Figure 5.1 illustrates the OLive-L approach. To detect and separate obstructed and successful traces (RLC-1), the *traces* are first *partitioned* accordingly. After this preprocessing, the approach then proposes a partial trace of events, i.e., a segment of the successful trace, to find paths to complete the obstructed trace (RLC-3). Such

J. Holderer, *Obstructions in Security-Aware Business Processes*, https://doi.org/10.1007/978-3-658-38154-7\_5

**Figure 5.1** The OLive-L approach for resolving obstruction based on logs

a *completion trace* could violate a safety property, such as an SoD requirement, but eventually allows the liveness to be "enforced" (in case a PAIS is provided that steers the execution accordingly). The proposed solution is again assessed with regard to its security-sensitivity. Indicators that quantify the cost of the obtained completion traces (RLC-2) are identified based on the log, enabling a measure of security-sensitivity for selecting the most security-sensitive candidate.

Figure 5.2 illustrates the OLive-L approach with example traces of an arbitrary model that are categorized as "successful" or "obstructed." Based on this partitioning of cases, the intention is to find the closest matches for the obstructed trace to the successfully executed traces. These nearest matches then propose the partial trace to complete the execution, and the example presented here results in two

**Figure 5.2** Log-based approach with example traces

candidates. An objective function tries to find, for example, the shortest completion trace, which could be justified based on the assumption that a shorter exceptional completion trace involving the minimal number of executed events may be less risky and more security-sensitive. If constraint definitions exist, then an objective function minimizes the number of violations a solution candidate implies.

Similarly to the OLive-M approach, this chapter demonstrates the applicability of OLive-L by using logs for resolving obstructed workflow executions. A subsequent illustration presents a realization of the OLive-L approach that exemplifies how process mining and machine learning methods are applied in this context. The OLive-L approach primarily addresses the obstruction resolving requirement (RLC-3), as well as depends on the partitioning of traces and the assignment of costs. Therefore, the other requirements of RLC-1 and RLC-2 are incorporated as essential building blocks. Chapter 2 previously examined various possibilities of using logs for the partitioning of logs (RLC-1) and how they can determine indicators and costs (RLC-2). This chapter complements these methods for partitioning by taking the SecANet into account to separate the traces.

Next, possible methods for exploring the similarity of traces are examined, resulting in identifying a common and applicable approach to provide solution candidates of successful traces that represent the closet match to the considered obstruction. Then, to finally select a candidate trace from which the completion trace is obtained, the ways to determine the security-sensitivity of candidates, i.e., the different costs they may imply, are illustrated. An implementation of the OLive-L approach offers experimental results based on a log synthesized from the CEW SecANet. Finally, a discussion considers further developments and extensions, such as the possibilities to assess security-sensitivity, and sketches how the logs may be used for the model-based approach.

#### **5.1 Methods and Realization of the OLive-L Approach**

This section identifies the methods to realize an implementation of the OLive-L approach, which builds upon the approaches and methods indicated in Chapter 2 that suggested the promising use or adaption of OLive-L. The required formalism is introduced, beginning with a trace replay performed on a SecANet considered for identifying the successful or obstructed traces. The partitioning of logs represents a fundamental initial step to provide further reason on the traces of the logs. For resolving an obstructed trace, the logs can also recommend or predict actions based on the behavior they reveal, such as how to complete the processes to achieve a positive outcome. Therefore, this section will then consider log-based techniques from process mining, in particular those from predictive monitoring suitable for determining nearest matches to select and demonstrate an appropriate method to resolve obstructions. The partitioning of logs further enables deriving meaningful measures for identifying the most security-sensitive candidate trace, where such indicators and measures are considered under the notion of "security-sensitive costing."

#### **5.1.1 Trace Replay**

To partition traces, a log may already provide enough information to directly categorize its traces as obstructed or successful, for example, by considering the attributebased filtering (e.g., "pi\_abort" in XES) or endpoints filter. Alternatively, the log may be classified by corresponding conformance checking artifacts, such as rule checking, replay, or alignments. Subsequently, based on the SecANet encoding, a straightforward way of conformance checking, the trace replay, is prepared and illustrated. If a fully replayed trace reaches the final marking, then it is considered successful. If it first reaches a terminal marking, then it is considered obstructed.

#### **5.1.1.1 Trace-Related Notations**

The basic definition related to traces and event logs is presented in the following.

**Definition 5.1 (Trace and Event Log).** *Given an alphabet of events, T* = {*t*1,..., *tn*}*, a trace is a word* σ ∈ *T* <sup>∗</sup> *that represents a finite sequence of events. An* event log *L* ∈ *B*(*T* <sup>∗</sup>) *is a multiset of traces.*

In the current context, an event consists of the executed task. The user who executes the task is denoted as < *task*, *user* >. Equivalently, a corresponding trace that contains events of such form is denoted as σ*tu*. Accordingly, the obstructed trace in Figure 5.2 is given as σ*tu*<sup>⊗</sup> = < *t*1, *u*<sup>1</sup> >, < *t*2, *u*<sup>4</sup> >, < *t*3, *u*<sup>2</sup> >, with the successful trace of σ*tuS* = < *t*1, *u*<sup>1</sup> >, < *t*2, *u*<sup>1</sup> >, < *t*3, *u*<sup>2</sup> >, < *t*4, *u*<sup>6</sup> >, < *t*5, *u*<sup>8</sup> >, < *t*6, *u*<sup>9</sup> >. Analogously to these language-related formalisms, the trace sequences beginning after the *i*-th position of the trace is indicated by σ*tuSi* . Then, the partial trace to complete the workflow is σ*tuS*<sup>3</sup> = < *t*4, *u*<sup>6</sup> >, < *t*5, *u*<sup>8</sup> >, < *t*6, *u*<sup>9</sup> >.

Similar to full firing sequences, full traces indicate a sequence of events that is fully replayable on a WF-net by taking the net from the initial to the end markings. The sequence definitions from van der Aalst [3] are adapted and extended to this notion, as well as the use of traces, so that partial and possibly incomplete traces can be defined and potentially concatenated with a completion trace.

**Definition 5.2 (Concatenation of traces, set of log events).** *A trace* σ *appended with element t is denoted as* σ *t* = *t*1,..., *tn*, *t . Similarly,* σ1σ<sup>2</sup> *appends the trace* σ<sup>2</sup> *to* σ1*, resulting in a trace of length* |σ1|+|σ2|*. This can be simplified as* σ*t or* σ<sup>1</sup> σ2*, respectively. For any log L* = {σ1,σ2,...,σ*n*}*, L*- = σ<sup>1</sup> σ2 -...σ*<sup>n</sup> concatenates all traces into a single trace of length* <sup>|</sup>σ1|+|σ2|+|...|+|σ*n*|*. Hence, supp*(-*L*-) *gives the set of all events that occur in all traces contained in the log.*

Appending the completion trace σ*tuS*|σ*tu*⊗| to the obstructed trace σ*tu*<sup>⊗</sup> can be denoted as σ*tu*⊗σ*tuS*|σ*tu*⊗| = < *t*1, *u*<sup>1</sup> >, < *t*2, *u*<sup>4</sup> >, < *t*3, *u*<sup>2</sup> >, < *t*4, *u*<sup>6</sup> >, < *t*5, *u*<sup>8</sup> >, < *t*6, *u*<sup>9</sup> >.

#### **5.1.1.2 Replay-Based Partitioning of Traces**

To replay the traces on the SecANet, the events of the trace may need enriching. For example, an event that encodes which user executed a task is represented as a distinct user-task transition and a corresponding task. In turn, the traces must consist of events containing the name of the executed task *ti* and the user *u <sup>j</sup>* who executed it. For the case that the traces are not easy to map and replay on the flattened model, it is first shown how the replay can be prepared. For this, events of the form < *ti*, *u <sup>j</sup>* > are mapped to the transitions of the model:

**Definition 5.3 (Replay preparation).** *For each event* < *ti*, *u <sup>j</sup>* > *of the traces* σ*tu occurring in the log Ltu, the corresponding transitions of the flattened SecANet N, i.e., the corresponding user-task transition tu <sup>j</sup> ti that assigns the user to its task and the transition ti indicating the task afterwards, are mapped to each other. By doing this, each event* < *ti*, *u <sup>j</sup>* > *of the trace* σ*tu is transformed to the sequence tu <sup>j</sup> ti , ti. The resulting trace is notated as* σ*utt , indicating the order of the transformed events. Analogously, the log is denoted as Lutt .*

The *log replay* algorithm is used to replay the resulting traces σ*utt* [175]. The transformation from the BPMN model into a P/T-Net [78] and the conducted flattening introduces transitions that are not visible in the log (e.g., the forks or joins that route the control flow).

Such invisible tasks are considered lazy. In other words, they might fire in order to enable succeeding visible tasks, i.e., the tasks from the BPMN model (*ti*) or usertask transitions (*tu <sup>j</sup> ti*), but never directly in the course of log replay because they do not have an associated log event [175]. If a trace σ*utt* is replayable by applying the *log replay* algorithm and reaches the final marking (with only one token remaining in the end position of the WF-net), then the trace is considered *successful*. Thus, the corresponding original trace σ*tu* is added to the set of successful traces *Ltu*S. If the trace σ*utt* is replayable and does not reach the desired final marking but some other terminal marking, then it represents an *obstruction* with its corresponding original trace σ*tu* classified as obstructed σ*tu*⊗. Traces not fully replayable, such as those resulting from the aforementioned incompleteness or noise (cf. Chapter 2.3), are neglected.

#### **5.1.2 Nearest Match**

Based on the performed classification of logs, given an obstructed trace (cf. Figure 5.2) that contains the executed tasks and its executor (e.g., σ*tu*<sup>⊗</sup> = < *t*1, *u*1 > ,< *t*2, *u*4 >, < *t*3, *u*2 >), the nearest match to the successful traces must be found to identify a partial sequence to complete the execution. To obtain the matches of traces that are in some way the "closest" to the obstructed trace, this section introduces the so-called k-nearest neighbor (kNN) search as a method to realize the OLive-M approach.

#### **5.1.2.1 k-Nearest Neighbor**

Identifying the nearest match and proposing an addition of events have strong similarities to the imputation of missing values for cleaning and imputing raw data. If the traces related to the OLive-M approach were considered as data points, then an obstructed data point could be imputed with the user-task events from the points that encode successful executions.

A popular imputation approach to correct missing values is based on the k-nearest neighbor search. For each instance that contains one or more missing values, the knearest neighbors are calculated, and gaps are imputed based on the existing values of the selected neighbors. The most commonly used similarity function to obtain the k-nearest neighbors for missing values imputation is a variation of the Euclidean distance that accounts for those samples containing missing values [27]. Along with being a typical method in machine learning (ML), predictive monitoring that leverage ML approaches often use kNN in addition to support vector machines, artificial neural networks, decision trees, clustering methods, or regression trees [144, 202].

The kNN algorithm is based on the Parikh vector representation, introduced previously, allowing for an easy transition of the results to Petri net-related matrix equations and Parikh vectors, which facilitate combining the elements and solutions of the log- and model-based approaches. Therefore, kNN is suitable to search for similarities between the data points used to realize the approach presented here.

**Figure 5.3** Sketch of obstructed and successful traces in n-dimensional space

Figure 5.3 sketches the points of successful traces related to an obstructed trace (o) that indicates the n-dimensional space in which kNN operates. Identifying those traces with the nearest distance to "o", a variety of similarity metrics exist, such as the Manhattan or Cosine distance. Because the straightforward applicability of the approach is of primary interest here, the Euclidean distance that corresponds to the typical spatial understanding of a distance is introduced. The distance of each selected data point to all other data points is computed sequentially, i.e., the computational steps increase linearly with the size of the problem. In this respect, the caveat of kNN lies in the dimensionality because the required space increases exponentially with each added dimension.

#### **5.1.2.2 kNN-Based Completion Trace**

The kNN algorithm, dating back to Cover et al. [56], is adapted for use in the OLive-L approach by finding the nearest match between an obstructed trace and the successfully executed traces. The completion traces are then identified based on these *k*-candidates.

**Definition 5.4 (Find k-nearest neighbors).** *Given a set of successful traces LtuS, an obstructed trace* σ*tu*⊗*, and a positive integer k, calculating the k nearest traces to* σ*tu*<sup>⊗</sup> *is performed as follows:*


<sup>σ</sup>*i*∈*LtuS where d is the Euclidean distance metric d*(*a*, *b*) = *<sup>n</sup> <sup>i</sup>*=1(*ai* <sup>−</sup> *bi*)2*.* 

*Given* {σ1, <sup>σ</sup>2, ..., <sup>σ</sup>*<sup>k</sup>* }*, the partial sequences of the corresponding traces* {σ1|σ*tu*⊗|*,* σ2|σ*tu*⊗|,..., σ*k*|σ*tu*⊗|} *contain all the events after the* |σ*tu*⊗|*-th position of the trace, presenting the k potential sequences of events to complete from* σ*tu*⊗*.*

If more than one candidate are found, then only one must be selected, for example, by an objective function that considers the length of the partial sequence to complete or the number of violations taken into account. For instance, if two successful candidates

$$
\sigma\_{\text{ltl\\$1}} = \langle , , , , ,  \rangle \text{ and } \langle , , ,  \rangle
$$

$$
\sigma\_{\text{IuS2}} = \langle , , , ,  \rangle
$$

are chosen as the nearest match, both having the same first three events < *t*1, *u*1 >, < *t*2, *u*1 >, < *t*3, *u*2 > in which only the executor of *t*2, namely *u*1, differs from the executor of *t*2 in the obstructed trace, *u*4, then the potential partial sequences of events to complete the execution, i.e., the completion traces

$$\sigma\_{\text{IuS1}|\sigma\_{\text{Iu0}}|} = \langle , ,  \rangle \text{ and}$$

$$\sigma\_{\text{IuS2}|\sigma\_{\text{Iu0}}|} = \langle ,  \rangle$$

can be compared by an objective function. If the length of the partial sequence of events is minimized, then the completion trace σ*tu*S2|σ*tu*⊗| is chosen to complete σ*tu*⊗.

#### **5.1.2.3 Security-Sensitive Costing of Candidates**

As examined in Chapter 2.3, the log can be used to enhance the model as well as the log by indicators, such that violations can be better assessed. Such a securitysensitive costing based on the log may consider a plethora of indicators that can be derived from the logs [17, 164, 165] and then incorporated and weighted into the overall cost of the related elements in the SecANet or the events of a log. More precisely, in addition to assigning indicators to places or transitions of a SecANet, these could also be assigned to each user-task event or each event that involves only a certain user or task. Then, the overall cost of each proposed candidate is summed to assess the solution in terms of its security-sensitivity.

This extraction of indicators and metrics used for security-sensitive assessments can focus on multiple aspects, some of which are presented in the following with examples:


Specifically, the consideration of social networks that use different metrics for the type of collaboration of actors can be assessed from a security perspective.

To offer additional examples, the social network analysis provides different metrics that seem suitable for use in security-sensitive costing. A relationship can result, for example, from how often multiple actors are involved in the same process execution. This so-called "working together" metric indicates that the process is being handled well, but there remains an increased risk of collusion or fraud. Furthermore, considering which actors perform similar tasks is possible. A user who carried out a task similar to the obstructed one could be favored by the costs. Finally, as identified in Chapter 2, process logs can contain events that represent the execution or completion of tasks, as well as provide more detailed information about the state of processing, which can include the assignment of an activity to a specific actor, whose actual start of editing is recorded in another event. Other event types can define delegations, pauses, resumes, and the end of activities (see the Standard Transactional Life-cycle Model in Chapter 2). Metrics that refer to an event type can, for example, explicitly track delegations and derive information about the hierarchy of process participants to be used for role mining. Such hierarchies can then be associated with costs. For instance, if the head of a department carries out an activity that an employee would otherwise perform, then this activity results in a higher cost.

Based on the classification of logs, the feature weighting of the partitioned classes can assess the security-sensitivity of a solution. In determining the influence of individual features, i.e., the dimensions in an n-dimensional space, as classified as a successful or obstructed trace, a high attribution of certain user-task events suggests that the existence of these features is crucial in the selection of candidates. Thereby, based on the typical RELIEF Algorithm [129], for example, the vectors are determined with a dependence on both classes, the nearest hit to the class under consideration and the nearest miss from the other class. Assessing the importance of the different events is then possible to make the entire trace successful or obstructed, respectively. The *k*-candidates can then be multiplied with the obtained feature vector, such that the candidate with the highest summed up weight represents that it contains most of the user-task assignments that are crucial for successful execution, and thereby provides a "completability measure." A feature vector for obstructability can also be deduced by a feature weighting of the obstructed traces where the minimum value is chosen, as it represents an "obstructability measure."

If there exists a SecANet model of the process, then replaying the overall trace σ*tu*⊗σ*tuS*|σ*tu*⊗|, i.e., the obstructed and completion traces, can also indicate the missing tokens during replay firing. When the SecANet has costs assigned, the cost to add missing tokens in the places, together with the cost to execute the transitions related to the events in the completion trace, sum to the overall cost of the solution.

### **5.2 OLive-L Experiments for Log-Based Obstruction Solving**

An implementation of the OLive-M approach presented above is demonstrated through the following experiments applied to logs and traces related to the CEW SecANet.

### **5.2.1 Implementation**

The implementation of the OLive-L obstruction solution was developed in Java 8 using the Apache Commons math library to calculate the Euclidean distance for the kNN algorithm. Based on two CSV files for the successful and the obstructed traces, and a positive integer value of *k* that encodes the vicinity to scan when finding the closest matches to a given obstructed trace, it returns a list containing at most *k* closest vectors, the related traces, and their distance from the obstructed trace vector. These experiments were conducted on a MacBook Pro with 8 GB RAM and an Intel Core i7 3 GHz CPU.


**Table 5.1** Encoding of successful traces in 12-dimensional space

#### **5.2.2 Experiment Preparation: Obtaining Traces**

Comparable to real WSP instances, because acquiring real-world traces with a corresponding model along with all the authorization data required to perform the described analysis is difficult, successful and obstructed traces were generated by playing out firing sequences of the flattened Petri net from Figure 3.46 (i.e., sequential firing of the enabled transitions until an obstructed or a final marking is reached). With this data generation method, both evaluations build upon the same model to compare the results.

After generating the traces, the events were mapped to the users who executed each, according to the flattened user-task assignment, and filtered only by the relevant user-task events (in a real-world log, such events would contain the task name with the executing user/originator, cf. Definition 5.3). From this, successful and obstructed traces conforming to the user-task assignment and SoD/BoD constraints were generated. For each trace of the form <sup>σ</sup>*tu*, the corresponding Parikh vector <sup>σ</sup>*tu* was build and assigned to the n-dimensional space. Table 5.1 displays the successful Parikh vectors of the traces as assigned to a 12-dimensional space, based on all possible user-task assignments.


**Table 5.2** Solution for *k* = 5 with highlighted partial sequence

#### **5.2.3 Experiment Setup and Solution**

The nearest neighbor of the successful traces to the corresponding obstructed trace was computed with the Euclidean distance measure. For comparability, the obstructed trace σ<sup>⊗</sup> from the model-based experiments, encoded as (0, 0, 1, 1, 0, 0, <sup>1</sup>, <sup>0</sup>, <sup>1</sup>, <sup>0</sup>, <sup>0</sup>, <sup>0</sup>), was also chosen. The solution for *<sup>k</sup>* <sup>=</sup> 5 is depicted in Table 5.2 1.

Trivially, if *k* = 1, then no decision is needed as to which partial sequence to choose. Interestingly, < *t*5, *d* > would be proposed, although the majority of

<sup>1</sup> The related event logs can be consulted at https://doi.org/10.6094/UNIFR/228177. The archive file olivel.zip includes a manual on how to reproduce the results.

successful traces for *k* = 5 in Table 5.1 ends with< *t*5, *a* >. Based on the candidates identified by the Euclidean distance, the *k* = 5 solution requires selecting one of these candidates with their completion trace by considering security violations or the minimum length of the partial trace. As the partial trace, i.e., the completion trace, is selected at the |σ⊗|-th position, the second and third solutions are empty. Because the remaining completion traces have the same length, the length-criterion to identify completion traces is neglected.

To assess the security violations of the completion traces, the obstructed trace is checked against the different solutions and impacts on the given SoD and BoD constraints. Similarly to the model-based approach, both solutions, < *t*5, *a* > and < *t*5, *d* >, violate one SoD constraint. However, reviewing the set of partial sequences provided in Table 5.2, a majority for < *t*5, *d* > can be identified. Additional techniques and corresponding limitations due to the uncertainties that a log may entail are discussed below.

#### **5.2.4 Experiments with Extensive Logs**

To illustrate the applicability of this implementation to real-world logs, the performance was tested on a large data set with a 65-dimensional space and 247,192 traces. This log did not allow partitioning based on a SecANet because no authorization specific data was available. Therefore, the traces were related to a randomly selected trace to assess the performance, and the qualitative aspect of the result had to be neglected. In this experiment, finding the five nearest neighbors for one trace required 0.31 seconds, which suggests the efficiency of the approach.

#### **5.3 Discussion and Potentials of the OLive-L Approach**

In realizing the OLive-L approach, this chapter first proposed an additional way to detect and separate obstructed and successful traces (RLC-1) by replaying traces on the SecANet model. The kNN method was leveraged to find the traces that complete obstructed execution (RLC-3). Depending on the actual capabilities of process monitoring, control, and enforceability that a PAIS provides, the solutions for the completion traces may only present a recommendation on how to proceed. Alternatively, the PAIS may steer the obstructed process towards its completion by the obtained completion trace. To determine the security-sensitivity of the solution candidates, in addition to examining the log-based indicators, the SecANet model quantified the costs of the proposed solutions (RLC-2). Based on the feature space spanned by all user-task events, the feature vector was illustrated as to how it can evaluate the significance of the events in a candidate trace, for example, with regard to the successful execution of the process. Because the presented methods represent one possible approach to realizing the building blocks of the implementation, the limitations that exist in each step, as well as possible improvements, are discussed in the following.

#### **5.3.1 Log and Partitioning**

The solutions strongly depend on the size and quality (e.g., in terms of noise or granularity) of the log, especially to the extent to which successful and obstructed traces appear. At the same time, the log allows considering only those executions that are relevant in practice.

The possibilities of partitioning traces are extended by the SecANet model. Although the result of this partitioning may initially appear as just a reflection of the firing sequences of the "played out" model or the terminal language of the net, considering the users and tasks that are part of real processes make a difference. The log reflects a concrete selection of real-world process executions, such that the possibilities to solve an obstruction are reasonably limited. Therefore, a model-based solution might lack practical relevance if it does not represent a solution within the log-based approach.

Another issue concerning the replay is that traces not fully replayable are neglected. However, these traces could still indicate "good" outliers that result from a break-glass situation that was resolved and reviewed, so they are no longer replayable by the (idealized) model. An event attribute could additionally indicate the trace as completed, such that it would be included via attribute-based filtering.

Apart from replaying the traces, further conformance checking artifacts, such as rule checking or alignments, could use the SecANet encoding to partition traces. For example, the alignment of the log traces to the firing sequences of the SecANet model could be computed such that deviations from the synthesized traces are relatable to violations and then introduce more classifications.

#### **5.3.2 kNN and Selection of Completion Segment**

Although the kNN-solution provides a way to escape an obstructed trace, the necessary assumptions leave room for discussion and improvement. Variants for finding the nearest neighbors, such as other distance measures of Manhattan, Cosine, or edit distance, could be explored. Alignments could also be used as an additional similarity metric to obtain the nearest matches of an obstructed trace to those successful executions.

When determining the completion trace, the approach also suggests opportunities for refinement when considering which events of the successful trace must be contained in the completion segment to complete the obstructed trace adequately. In contrast to the model, many uncertainties exist in the traces. For example, the obstruction does not necessarily occur in the final task of the obstructed trace. The reason for the obstruction might appear early in a trace, and concurrent activities could follow. Currently, the length of the obstructed trace is key for choosing the completion segment, i.e., the completion trace, because traces of equal length may have similar execution paths, so they already inherit a certain similarity. Candidate traces that have the same tasks executed after a certain length within the total of the obstructed trace could additionally be required. However, if this is not the case, then the completion segments of a candidate may become too short, such as in the second and third experimental candidates in Table 5.2.

Therefore, other techniques could be considered to determine the partial trace. The last common task of the obstructed and the considered candidate trace when traversing the traces from left to right might be considered. Alternatively, the Parikh vector of the obstructed trace could be subtracted from the Parikh vector of the candidate trace. Then the remaining events in the Parik vector of the successful trace could be executed according to the order of occurrence in the corresponding trace. Based on predictive monitoring approaches, the next task of an obstructed trace could be predicted, such that the subsequent event or the starting point of the completion trace may be determined. Finally, by using a SecANet model, traces could be replayed and obstruction markings identified. Then, the marking obtained related to the obstructed marking can be checked, along with a determination of the remaining activities to be executed. For simplicity in this implementation, however, the length of the obstructed trace was chosen to be the most straightforward to illustrate the applicability of the approach efficiently.

#### **5.3.3 Security-Sensitive Costing**

Additional factors could be considered (e.g., in an objective function) to better assess the security-sensitivity. Implications regarding security violations from choosing the closest trace could also take additional features into account by conformance checking of an SoD rule for classifying the traces accordingly. A feature weighting could further partition traces regarding violations. Having logs portioned into classes of "conforming" and "violating," a corresponding feature vector could then perform a security-based weighting instead of a pure success-based weighting. From this feature weighting, the events that contribute to violations could be indicated.

Additional indicators and measures could be refined using the manifold approaches sketched by machine learning and process mining. For example, the partitioned obstructed traces for predictive or prescriptive monitoring could predict obstructions to direct avoidance. Alternatively, these traces could be hypothetically completed when considering each as a completion trace to ensure that the proposed solution has a low risk of being obstructed again. Because the current focus, apart from the feature weighting, is on the successful traces, the advantage of this knowledge within the obstructed traces can be leveraged.

#### **5.3.4 SecANet Discovery**

If no SecANet is available, then mining a SecANet in the course of "process discovery" is conceivable. In this case, discovering all aspects separately is advisable, including the control flow and all user-task assignments of the complete executions. Some reasonable assumptions must be made for mining the SoD or BoD constraints. For example, the pairs of tasks that usually involve different users at the case level could be investigated and then defined as SoD constraints for these tasks. As identified in Chapter 2.3, process mining techniques focus on various resource perspectives, e.g., role mining, that may be used or adapted here. Then, an adequate process discovery method can obtain the control flow, user-task assignments, and constraints as inputs based on which of the usual SecANet encoding, as described in Chapter 3, could be performed, enabling the discovery of a SecANet based on a log to which the OLive-M approach is applied.

#### **5.3.5 Log- and Model-Based OLive Extensions**

When assessing violations, the SecANet is already considered by a replay to identify missing tokens during firing. However, additional specialized ways are sketched below that not only consider the SecANet but the respective model or log-based counterparts of the OLive approaches to resolve obstructions. The sequences of usertask events (σ*tu*) and user-task transitions σ*utt* are assumed to be mapped according to Definition 5.3. Therefore, the advantages of how both methods of the log- and model-based technique can be combined are explored in the following.

#### **5.3.5.1 OLive-LM: Refining the Log-Based approach with the Model-Based approach**

In addition to using the SecANet to assess security-sensitivity, elements of the model-based OLive-M approach can assess violation. For example, the obstruction trace on the SecANet can be replayed to the end in the obstruction marking, followed by the candidate trace without the partial trace for completion. From the perspective of the model-based approach, the resulting marking represents a live marking that must be reached from the obstructed marking to fire the partial trace to complete the execution. By subtracting the place vector of the obstructed marking from the place vector of the live marking, the result could reveal the tokens that must be added to complete the execution. If there are no positive integer solutions of the tokens to add, then the solution may be too far from the model, such as when tasks are skipped.

Eventually, in the case of the resulting vector ≥ 0, based on the added tokens and the events in the partial completion trace, the costs of the related places and transitions can be summed. To perform such a cost-based evaluation, the corresponding costs can then be assigned to the model during the log-based model-enhancement.

#### **5.3.5.2 OLive-ML: Refining the Model-Based Approach with the Log-Based Approach.**

Just as the OLive approach can be leveraged for the log-based approach, logs can be integrated into the model-based OLive-M approach to provide more realistic and possibly faster solutions. Two possibilities are considered in checking the solution Parikh vector *X* of the OLive-M approach with the corresponding traces or directly inserting the successful partial traces of the log as a Parikh vector *X* into the marking equation.

**Using Logs to Address the Problem of Replayability:** The first option of checking the solution Parikh vector *X* of the OLive-M approach with the corresponding traces addresses the problem of replayability. In contrast to the replayability of the Parikh vector, the log replay has the advantage that the traces in the partitioned log already contain an order that can be deduced by the trace tuple or by the timestamp of the corresponding trace event, if provided. After the ILP model involving the OLive-M state equation is solved, the resulting *X* vector is related to the logs. The solution also provides a live marking *mli*v*<sup>e</sup>* that consists of the obstructed marking *m*<sup>⊗</sup> and the addition of the tokens in .

Instead of checking the replayability of the solution vector *X*, the transitions or events in *X* could be checked if they are completely contained in some of the successful traces. To filter only those traces that correspond to the solution, *X* must be fully contained in the Parikh vector of each of the considered traces σ*uttS*, i.e., <sup>σ</sup>*uttS* <sup>∈</sup> *Lutt*<sup>S</sup> and <sup>σ</sup>*uttS* <sup>≥</sup> *<sup>X</sup>*. For each identified traceσ*utS*, the replay of the trace without the events in the Parikh solution, i.e., <sup>σ</sup>*ut* <sup>−</sup> *<sup>X</sup>*, can be checked if it ends in *mli*v*e*. This could either be checked by a SecANet replay, or directly by the marking equation *mli*v*<sup>e</sup>* <sup>=</sup> *<sup>m</sup>*<sup>0</sup> <sup>+</sup> *<sup>A</sup>*(σ*utS* − *X*). Therefore, the replay on the model directly excludes those traces that have gaps in the firing sequences, which occur in the subtraction of the Parikh vector. In contrast, the extent to which checking the replay by the marking equation is sufficient would have to be considered.

Finally, if the live marking obtained after replaying the sequence is equal to the live marking obtained by the OLive-M solution by adding to *m*⊗, then *X* is replayable because it contains all the events that have not yet been replayed from the successful trace. This combined model- and log-based approach excludes spurious solutions and eliminates the possibly exhaustive replay analysis of the Parikh vectors, as described in Chapter 4. Moreover, relating the ILP solution of *X* to a limited set of successful traces does not necessarily suggest a restriction on the possible ILP solutions. If no corresponding trace is available to check *X*, then the replayability of *X* can still be examined, as described in Chapter 4. By using logs to check replayability, the combination of the model and the log shows a method, assuming that a small ILP instance can be solved efficiently, for how a solution that resolves obstructions is achieved efficiently.

**Using Logs to Address the Problem of Larger ILP Instances:** The second option of inserting successful partial traces of the log directly as the Parikh vector *X* in the marking equation allows for solving a system of linear equations instead of an ILP instance. A simplifying assumption for this method is that only successful traces with the same tasks in the same order as in the obstructed trace are selected. The completion segment of such a successful trace σ*uttS* ∈ *Lutt*<sup>S</sup> is denoted as σ*uttS*|σ*tu*⊗|, where σ<sup>⊗</sup> denotes the sequence that leads to the obstruction marking.

As mentioned above, this choice of the completion segment can be significantly more multi-faceted and differentiated. Although the simplifying assumption allows for a fast identification of possible solutions by setting *<sup>X</sup>* <sup>=</sup> <sup>σ</sup>*uttS*|σ*tu*⊗|, additional solutions could be lost. By inserting these values assigned to *X*, every linear equation has only one independent variable such that can be directly solvable. Based on these observations, the solutions can be further restricted by such that 0 ≤ ≤ 2 in which the result only allows for the addition of single tokens. A solution means that the process can be completed by adding the obtained tokens and firing the completion sequence σ*uttS*|σ*tu*⊗|. As before, the costs can be identified for each possible solution based on the assigned cost in the model. After solving each possible successful trace, the solution with the least cost can be identified. While this solution approach is efficient for systems of linear equations, smaller ILP instances may be more exhaustive. With increasing problem sizes, a considerable amount of space is required but remains efficiently solvable compared to larger ILP instances.

In summary, while the OLive-M approach may be practical for smaller ILP instances, depending on the sizes of the log and the possibly larger ILP instances, the first or second options presented above must be determined as to which is more suitable to enhance the OLive-M approach based on logs. So, the logs can build a solution base to be included if necessary. In both approaches described in this section, the finite nature of the logs could be used to ease computation and limit solutions to realistic possibilities. The additional computing steps are light, such as the linear search of comparing the *X* vector with each Parikh vector of the successful traces. In addition, by the Parikh mapping, all traces can be transferred as points into an n-dimensional space, such that a point encodes multiple traces that have been used to execute the same events in a different order. This simplification of the representations of the traces to check reduces the search space and memory requirements. A log already contains a certain degree of evidence for how the real-world executions may work, so by using logs, the results of the model-based approach can be adjusted to reality. As a drawback to using logs, the theoretically conceivable solutions that do not appear in the log are potentially suppressed. Complementing logs with successful traces synthesized from the SecANet model can be considered to counter this scenario. However, because synthesis means computing the reachability, this must be done in a workable way. Otherwise, only checking the replayability when required is more appropriate.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

The innovative and disruptive power with which the digital transformation changes organizations along with more regulations force enterprises to automate the implementation of regulatory rules in their information systems. The tendency of these regulations to unintentionally impede the operative business is consequently increasing. Although the concepts of governance, risk, and compliance management set a framework for the realization of regulations, their implementation in enterprise information systems for automating business processes can lead to technical obstructions, which occur from the enforcement of access control security that blocks the execution of business processes or an additional combination with an unexpectedly diminishing user base. The potential occurrence of such obstructions has an increasing effect on the high-level of uncertainty organizations must deal with. However, this challenge has not been sufficiently addressed. By developing methods for the analysis, detection, and handling of obstructions, this dissertation contributes to the engineering of information systems that provide flexible solutions to harmonize the conflicting goals of business and security at the process level. The introduction of indicator-based process security extends classic IT security concepts and provides a conceptional basis for the work. By considering indicators for compliance, the processes once again perform within the comprehensive frame designated by corporate governance. In this way, an obstructed process execution may still be completed within compliance while recognizing security requirements.

The Petri net-based SecANet representation covers the different aspects of a security-aware business process that incorporates indicators by providing a comprehensive starting point for analysis, detection, capturing, and resolution of obstructions. The model-based OLive-M approach then resolves an obstructed state with minimal security violations by considering the indicators assigned to the SecANet nodes as costs. Moreover, based on an obstructed trace, the log-based OLive-L method detects the most similar historical successful trace to complete

J. Holderer, *Obstructions in Security-Aware Business Processes*, https://doi.org/10.1007/978-3-658-38154-7\_6

the process. Both approaches constitute use cases of the net and propose to which users the tasks are to be assigned to security-sensitively resolve obstructions. Therefore, the SecANet, OLive-M, and OLive-L methods compose a holistic approach that addresses obstructability by considering all inputs (model, policy, log) resulting from the design, runtime, and audit phases of a security-aware process. More specifically, the contributions of this thesis are summarized as follows:


provides a detailed basis to answer questions about obstructions in business processes against existing research. The approach also facilitates the application of existing Petri-net (or workflow net-related) analysis methods, such as an analysis of the language-based properties of a SecANet, the introduction of SecANet soundness, as well as the possibility to create workflow-net characteristics for a SecANet (SecA-WF-Net). The developed SecANet+ approach integrates additional restrictions modularly, e.g., encoding the user's (un)availability to investigate resilience.


The developed methods are evaluated as effective. The SecANet allows for the identification of obstructions, and the construction of SecANet models can be formally proven that the behavior of the original process model is preserved. Theoretical worst-case considerations show that the complexity of the SecANet encoding has polynomial runtime behavior and constant space requirements. The increased structural complexity that a SecANet entails must be weighed against its added value. Empirical analyses based on generated security-aware process data and realworld examples provide strong indications that the complexity of solving SecANetbased WSP instances undercuts the runtime of typical SAT-Solvers. The analysis of obstructability is more complex however still moderate for mid-sized problem instances. The OLive-M and OLive-L approaches effectively resolve obstructed executions through experiments that find solutions to correct obstructions, even in larger models or logs. For common smaller problem instances, the experiments suggest that the methods discover solutions efficiently in terms of time and memory consumption.

This work tackles the uncertainty of if a security-aware process contains obstructions that paradoxically result from the intention to achieve a supposedly secure state through the enforcement of security controls. Thus, handling such obstructions can improve security in business processes. By adding process execution sequences representing compliant behavior, resolving obstructions in a security-aware and process-aware information system extends the intrinsic limits of mechanisms that enforce safety-oriented access control security. By opening up security-sensitive behavior that complements classic security concepts, business goals can be considered along with reducing the risk of fraud when computing solutions to obstructive situations. The approaches contribute to the security-aware automation in PAISs and facilitate the implementation of the increasing number of regulations and regulatory changes. The "digesting" of regulation and interpretation regarding the weighting of risks and costs remains a challenging problem and must be approached based on the entrepreneurial context from which this thesis abstracts. In a broader context, by developing automated methods that consider empirical aspects, this work contributes towards the advancement of reliable, agile, and autonomous solutions in information systems that leverage recent advances in big data analytics, artificial intelligence, and machine learning. In addition, research in future access control systems for PAIS is expanded within the fields of information systems and cybersecurity, which are also concerned with economic benefits and solving practical problems.

#### **6.1 Application**

Along with contributing to existing research related to satisfiability and resilience, this work provides a solid foundation for future research in the field of obstructability in security-aware processes and the development of software tools for the analysis and handling of obstructions. The integration of the developed methods into a software solution for the security-aware analysis of business processes, the Security Workflow Analysis Toolkit (SWAT), provides a foundation to transfer the contributions of this work1. SWAT contains methods for the preventive model-based or forensic log-based analysis of business processes and verification of security properties to show the principal integrability of the developed methods in a PAIS. These methods enable process designers and auditors to bridge the gap between the technical level on which corresponding methods operate and the business level they interpret.

In particular, the WF-Net-oriented Petri-net editor developed therein allows for the analysis of obstructability and satisfiability2. Simultaneously, based on the encoding, existing Petri net analysis tools can be used for the reasoning on obstructability and satisfiability, which lowers the hurdle of leveraging these approaches. The model- and log-based techniques integrate additional solvers (ILP) and software libraries (kNN), respectively. To optionally assign costs to the nodes in a SecANet, these approaches rely on P/T cost Petri nets (P/TCost-nets), which extend the Petri net type definition (PNTD) of Place/Transition nets used in SWAT.

The use of the developed methods in a PAIS could manifest in practical applications. In the design and audit phases, the methods can make the security-aware process specification less obstructive, satisfiable, more resilient, or assess the associated risks, e.g., of obstructability. The occurrence of obstructive sequences of user-task assignments and task executions, which are subjected to a more detailed investigation, can be retraced and visualized in detail with the help of the Petri net model representation. Concerning the structural complexity of SecANet models, the concentration on self-contained security-aware sub-processes, i.e., only users exclusively authorized for tasks of the sub-process, seems to be useful to maintain clarity. During runtime, applying the developed methods to resolve obstructions could recommend who performs which tasks, for example, in a "Break-the-Glass" situation, or as an assisted delegation, showing the potential best delegates (with the least violation) to the delegator. However, to adequately tackle the implementation of regulations, automating the handling of obstructions is crucial. In this example, the efficient solvability of practical problem sizes of security-aware processes suggests that solving obstructions in a timely (online) fashion is realistic. The automated application of the methods in a PAIS then mimics an autonomous delegator that assigns outstanding tasks to the appropriate users based on experience, competence, and expertise. A PAIS usually offers task assignments to its users, typically as work items, so could also provide additional mitigating actions by creating "break-

<sup>1</sup> See https://doi.org/10.6094/UNIFR/228177 for a manual on how to use SWAT and related tools in the SecANet context.

<sup>2</sup> For example, successfully checking the WF-Net conditions "option to complete" or "no dead wf-task" resolves a SecA-WF-Net as obstruction-free or satisfiable, respectively.

able" work items. Similar to typical "Break-Glass" scenarios, these could imply that the resolved obstructed cases are prioritized for audit.

#### **6.2 Extension**

The developed methods, especially the framework established by the SecANet approach and the theoretical basis, offer room for extension and adaptation into further questions of security-aware business processes. Three possible directions are identified in the following.

#### **6.2.1 Beyond Security-Sensitivity: Multi-Objective Solutions**

The OLive-M approach can be used to determine the resilience of a uniformly costed SecANet to estimate the minimal amount of users needed to complete a workflow. In addition, it could exclusively incorporate resilience-oriented indicators, e.g., the probability of user presence or the working together and handover-of-work metrics from social network analysis. Then, in the case of a non-resilient workflow or an unexpected user-absence that obstructs the execution of the process, a resilience-sensitive solution can be identified. Although security-related obstructions can correlate to the sudden non-availability of users, security and resilience remain at odds. A security-aware business process without any security requirements are trivially the most resilient and require only one user who is allowed to perform all tasks. The solution of a security-related obstruction with additional consideration of the resilience must lead to a trade-off solution. Multiple cost dimensions beyond security-sensitivity alone should be included and weighted to find an optimal solution for adequately addressing this multi-objectivity. As a plastic example, depending on the entrepreneurial and regulatory context, a dashboard offered by a PAIS could be used by a Chief Compliance Officer to set the weighting of the security- and resilience-oriented parameters by two sliders. In this way, further objectives assigned as a separate cost dimension, for example, regarding the performance of the process (KPI), could be added. The unraveling of presumably opposing indicators so far settled in a single cost dimension would be enabled through a more fine-grained approach that better reflects reality.

#### **6.2.2 Beyond the Case: Inter-Instance- and Inter-Process-Related Obstructions**

By expanding the focus from single process executions to the overall interrelations between processes orchestrated and steered by a PAIS, new problems regarding obstructive situations could be identified that accompany new possibilities for solutions beyond the individual case perspective. The SecANet encoding must then be extended to represent entire process architectures, e.g., with constraints between processes or their instances and users participating in different processes. Obstructions could result from the dependencies within the execution of several processes and their interplay with the overall policy. Besides control-flow dependencies between processes, this could affect the data flow, e.g., when a process is waiting for a processing file to complete because another obstructed process is idly accessing the file. Such more complex security-aware workflow specifications could also be related to satisfiability and resilience aspects. For example, requesting a vacation in such a system would reveal the impact of a user's absence from a process and provide a realistic overall view to determine the possibility of increasing obstructive risk or changing levels of resilience.

For resolving obstructed processes, this approach also makes it possible to consider the affected case along with its relation to other ongoing process executions, such as the users involved. An indicator could then correspond to the importance of executing specific (core) processes against the background of all processes running in a PAIS.

#### **6.2.3 Beyond Predictions: Corrective Monitoring upon Occurring Obstructions**

Due to the comparable problem setting, the developed methods can complement predictive monitoring by considering obstruction-related metrics as outcome-oriented predictions. Considering an obstructability metric during execution is comparable to an obstruction-free enforcement mechanism. For example, depending on a certain threshold of the obstructability metric, an attempt to assign a user to a task may or may not be permitted. Correspondingly, a completability metric that also captures the similarity of the execution to obstructed sequences, or a trend metric indicating if a process execution is tending towards an obstruction or completion, could refine predictions.

The predictive monitoring within the process mining could be complemented through a further step that prevents or avoids process execution from "going wrong," while also correcting an occurring obstruction at runtime as a variant of online process mining. Such corrective monitoring can resolve the obstructed process execution at runtime by steering it to completion on-the-fly.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Bibliography**


*29, 2011, Revised Selected Papers, Part I.* Ed. by Florian Daniel, Kamel Barkaoui, and Schahram Dustdar. Vol. 99. Lecture Notes in Business Information Processing. Springer, 2011, pp. 169–194. ISBN: 978-3-642-28107-5. URL: https://doi.org/10. 1007/978-3-642-28108-2\_19.


*BPM 2017 International Workshops, Barcelona, Spain, September 10–11, 2017*, Revised Papers. Ed. by Ernest Teniente and Matthias Weidlich. Vol. 308. Lecture Notes in Business Information Processing. Springer, 2017, pp. 475–483. ISBN: 978- 3-319-74029-4. URL: https://doi.org/10.1007/978-3-319-74030-0\_37.


Steven Miller, Jianying Zhou, and Gail-Joon Ahn. ACM, 2015, pp. 297–308. ISBN: 978-1-4503-3245-3. URL: https://doi.org/10.1145/2714576.2714633.


Alessio Bechini, and Jiman Hong. ACM, 2015, pp. 1245–1248. ISBN: 978-1-4503- 3196-8. URL: http://doi.acm.org/10.1145/2695664.2699497.


*ber 5–6, 2016, Proceedings*. Ed. by Ivica Crnkovic and Elena Troubitsyna. Vol. 9823. Lecture Notes in Computer Science. Springer, 2016, pp. 79–87. ISBN: 978-3-319- 45891-5. URL: https://doi.org/10.1007/978-3-319-45892-2\_6.


8260. Lecture Notes in Computer Science. Springer, 2013, pp. 240–254. ISBN: 978- 3-642-42000-9.


ciari, and Zbigniew W. Ras. Vol. 8399. Lecture Notes in Computer Science. Springer, 2013, pp. 67–81. ISBN: 978-3-319-08406-0. URL: https://doi.org/10.1007/978-3- 319-08407-7\_5.

